On ne disparaît pas après la livraison.
Un outil, ça vit. Ça évolue. Ça plante parfois. On est là pour tout ça.
Parler de mon outil
Votre outil est en production. Il tourne. Les utilisateurs s'en servent tous les jours. Tout va bien.
Jusqu'au jour où une API tierce change sans prévenir. Où un utilisateur trouve le cas limite auquel personne n'avait pensé. Où votre process évolue et l'outil doit suivre. Où un truc qui marchait parfaitement hier ne marche plus du tout ce matin.
Ce jour-là, vous aurez besoin de quelqu'un qui décroche. Qui connaît le code. Qui peut intervenir vite, sans passer trois jours à comprendre comment c'est fichu.
On préfère être ce quelqu'un plutôt que vous regarder chercher frénétiquement le numéro d'un ancien presta qui a changé de boîte entre-temps.
Concrètement.
Corriger ce qui casse
Un bug en prod. Un comportement bizarre. Un truc qui marchait hier et plus aujourd'hui. Ça arrive, même sur du code propre. L'important c'est la réaction.
On diagnostique. On identifie la cause. On corrige. On teste. On déploie.
Dans la journée si c'est critique, pas dans trois semaines après cinq relances.
Faire évoluer l'outil
Votre besoin a changé. Vos utilisateurs réclament une fonctionnalité. Un process interne a évolué. La réglementation a bougé. Vous avez une nouvelle idée.
On adapte. On ajoute. On modifie. Pas besoin de lancer un nouveau projet à chaque évolution.
L'outil grandit avec vous, sans rupture.
Garder la technique à jour
Les frameworks vieillissent. Les failles de sécurité se découvrent. Les dépendances deviennent obsolètes, puis incompatibles, puis dangereuses.
On met à jour. On patche. On upgrade. On maintient le socle en bon état.
Vous n'avez pas à surveiller les alertes de sécurité. On le fait pour vous.
Répondre aux questions
Un utilisateur bloqué qui ne comprend pas comment faire quelque chose. Un doute sur un fonctionnement. Un comportement qui semble bizarre mais qui est peut-être normal.
On répond. Par mail, par Slack, par téléphone si c'est urgent. Rapidement.
Par des gens qui connaissent votre outil, pas par un formulaire.
Surveiller avant que ça pète
Monitoring. Alertes. Logs. Tableaux de bord techniques. On garde un œil sur votre outil même quand vous n'y pensez pas.
Si quelque chose déconne (lenteur inhabituelle, erreurs qui se multiplient, espace disque qui se remplit, API externe qui ne répond plus), on le voit. Souvent avant vos utilisateurs.
La meilleure maintenance, c'est celle où on résout les problèmes avant que vous sachiez qu'ils existaient.
Comment ça marche.
Le forfait mensuel
Une enveloppe d'heures réservées chaque mois. Vous l'utilisez comme vous voulez : bugs, évolutions, questions, petits ajustements. Ce qui n'est pas consommé se reporte (dans la limite du raisonnable).
C'est la formule pour les outils en production avec des vrais utilisateurs. Ceux où on ne peut pas se permettre d'attendre.
L'intervention ponctuelle
Pas d'engagement, pas de forfait. Vous appelez quand vous avez besoin. On intervient, on facture le temps passé.
C'est la formule pour les outils stables qui bougent peu. Ou pour les coups de main occasionnels.
La reprise d'existant
Votre outil a été développé par quelqu'un d'autre. Le dev a disparu, l'agence ne répond plus, le freelance est parti élever des chèvres.
On reprend. On commence par un audit pour comprendre l'état du code. On stabilise. On documente. Et ensuite on maintient, ou on vous dit cash s'il vaut mieux reconstruire.
Combien ?
C'est pour vous si…
On est là pour ça.
Vous avez un outil en production et l'idée qu'il plante un vendredi à 18h vous empêche de dormir.
Votre ancien prestataire a disparu et personne en interne ne comprend le code.
Vous voulez faire évoluer votre outil mais vous n'avez pas les mains dedans.
Vous préférez payer un forfait raisonnable chaque mois plutôt qu'une facture astronomique le jour où tout casse.
Reprendre un code qu'on n'a pas écrit.
C'est jamais simple. Et on ne va pas vous mentir : c'est parfois un sacré chantier.
Le code peut être propre, structuré, documenté. C'est le cas idéal. On prend nos marques en quelques jours et on est opérationnels.
Le code peut aussi être un plat de spaghettis sans tests, sans documentation, avec des raccourcis partout et des « solutions temporaires » qui ont cinq ans. C'est plus courant qu'on aimerait.
On ne juge pas. On a tous écrit du code dont on n'est pas fiers, sous la pression d'une deadline ou d'un budget serré. L'important c'est ce qu'on en fait maintenant.
On commence par un audit. On ouvre le capot, on cartographie l'architecture, on évalue les dépendances, on identifie la dette technique, on repère les bombes à retardement. On vous fait un rapport clair : ce qui va, ce qui ne va pas, ce qu'il faut traiter en priorité.
Ensuite, deux chemins possibles.
Premier chemin : le code est récupérable. On stabilise, on documente, on prend la maintenance.
Deuxième chemin : le code est trop fragile. On vous le dit franchement, et on parle plutôt de refonte.
Dans les deux cas, vous savez où vous en êtes. Plus de zone d'ombre.
Pourquoi nous ?
Questions fréquentes.
Nos applications tournent sur une infrastructure OVHcloud, l'acteur cloud européen le plus certifié. Vos données restent en France, sous droit européen, dans des datacenters audités.
Voir les certifications
Votre outil mérite quelqu'un qui répond.
Un projet qu'on a construit ou un existant à reprendre : on s'en occupe.
Parler de mon outil Demander un audit