Pendant longtemps, le métier du logiciel a séparé deux mondes : ceux qui construisent (Build) et ceux qui font tourner (Run). Cette frontière a une raison historique, mais elle coûte cher au client. Nous l'avons supprimée chez nous. Voici pourquoi.
Le modèle classique : une passe de relais qui rate
Dans la plupart des prestataires, vous travaillez d'abord avec l'équipe Build pendant la conception. Une fois l'application livrée, on vous présente l'équipe Run — souvent des inconnus — qui reprend la maintenance. Ils découvrent le code, vos contraintes, vos utilisateurs. Vous, vous réexpliquez tout.
Ce passage de témoin perd énormément d'information. Les choix techniques implicites, les arbitrages métier qui n'apparaissent pas dans le code, les conversations qui ont eu lieu pendant la conception : tout s'évapore. La nouvelle équipe Run a deux options : tout redécouvrir, ou ignorer ce qu'elle ne sait pas. Les deux options coûtent cher.
Le choix d'unifier
Nous avons fait le pari inverse. Les personnes qui ont imaginé votre produit sont aussi celles qui le veillent. Pas pour faire de l'astreinte 24/7 — ce n'est pas leur métier — mais pour garder le contexte vivant.
Concrètement, votre chef de projet, votre designer et au moins un ingénieur restent en lien avec votre produit tant qu'il vit. Si vous demandez une évolution six mois après la mise en ligne, la même personne vous répond. Pas un ticket, pas un inconnu : la personne qui a co-conçu votre produit.
Ce que ça change concrètement
- Les évolutions arrivent plus vite : pas besoin de réexpliquer le contexte à chaque fois.
- Les incidents sont diagnostiqués plus rapidement : l'équipe connaît les choix techniques qui ont mené à l'état actuel.
- Les arbitrages sont plus justes : on sait pourquoi telle décision a été prise lors du Build, donc on sait quand il est sain de la remettre en cause.
- La dette technique est mieux contenue : ceux qui l'ont créée ont aussi le devoir de la résorber.
Le rôle de nos agents IA dans ce modèle
L'unification du Build et du Run n'est tenable que parce que nos agents IA prennent en charge la couche basse du Run : surveillance, alertes, sauvegardes, mises à jour de sécurité. Sans eux, demander à un designer de surveiller des métriques de prod serait absurde.
Avec eux, le designer reste designer. Quand quelque chose mérite son attention, l'agent l'alerte. Le reste du temps, il bâtit l'évolution suivante.
Pourquoi peu d'acteurs font ça
Parce que c'est exigeant. Cela suppose des équipes pluridisciplinaires, des outils internes solides, et une culture qui considère le Run comme aussi noble que le Build. Dans beaucoup de structures, le Run est encore vu comme une corvée à refiler à un junior. Chez nous, c'est l'inverse : c'est là qu'on apprend ce qui marche vraiment chez nos clients.
Une équipe qui ne voit jamais son outil tourner en production finit par concevoir des choses qui ne tournent pas en production.
— Un de nos ingénieurs, qui avait travaillé dans une grosse SSII avant
Et pour vous ?
Si vous démarrez un projet avec nous, vous rencontrez votre équipe une fois. Cette équipe vous accompagne pendant des années si vous le souhaitez. C'est le contrat implicite de notre modèle : pas de passation, pas de réintroduction, pas d'amnésie.