De l'idée au logiciel fonctionnel : à quoi doit ressembler le cycle de vie complet du développement ?

Une étude de GitHub a montré que les développeurs utilisant Copilot terminaient leurs tâches 55 % plus vite que ceux qui ne l'utilisaient pas. Des outils comme GitHub Copilot et Cursor, qui s'appuient sur de grands modèles linguistiques tels que Claude ou GPT, sont conçus pour automatiser les tâches fastidieuses de la programmation afin que les ingénieurs puissent se concentrer sur des problèmes plus complexes et plus créatifs. Grâce à ça, de nouveaux dépôts apparaissent chaque semaine. La promesse est tenue.

Mais où sont les produits ?

La contrainte n’est plus seulement l’écriture du code, mais tout ce qui l’entoure : le contexte partagé, la révision, la collaboration et une boucle de rétroaction qui te permet de savoir si ce qui a été livré fonctionne réellement. 

Comme le dit Fabien Potencier, CTPO chez Upsun et auteur des « 8 étapes de maturité de l’ingénierie IA » : « Tout repose sur le travail avant l’écriture du code et celui qui suit. » Kateryna Dvornichenko, responsable produit pour Upsun Dispatch™, précise ce que ça signifie concrètement : « Livrer plus de code ne veut pas dire livrer un meilleur produit. »

Alors, à quoi doit ressembler le cycle de vie complet du développement pour vraiment combler ce fossé ?

L’intention avant le résultat

La première étape du cycle de vie est celle que l’IA ignore complètement. Avant qu’un développeur n’écrive la moindre ligne, quelqu’un doit savoir quoi créer et pourquoi. Ça semble évident. En pratique, la plupart des équipes sautent cette étape dans leur précipitation à produire.

L’intention, ce n’est pas un cahier des charges. C’est la réponse à la question de savoir si l’idée vaut vraiment la peine d’être concrétisée. Upsun Dispatch™ vise en fin de compte à réduire le nombre de start-ups qui échouent, car les équipes se rendent compte plus tôt qu’une idée est mauvaise et l’abandonnent avant de dépenser des sommes importantes pour créer quelque chose qui sera voué à l’échec dès le départ. Ce genre de prise de conscience nécessite un jugement humain et une véritable étude des utilisateurs, pas un générateur de code plus rapide.

C’est aussi là que commence l’ingénierie contextuelle. La description que fait Fabien du problème de l’amplificateur est exacte : « Si tu as une base de code propre, bien testée et bien documentée, le LLM est plus performant. Si tu as un projet en pagaille, ça produit encore plus de pagaille, et plus vite. » 

La qualité du résultat d’un agent dépend entièrement de ce qu’on lui fournit en entrée. Un mauvais contexte, une intention vague ou une base de code fragile en amont produisent un mauvais résultat en aval, plus vite qu’une équipe humaine ne l’aurait fait. La vitesse amplifie ce qui existe déjà, que ce soit bon ou mauvais.

Ça veut dire qu’il est aujourd’hui plus important que jamais de bien cerner l’intention. Sauter les étapes de découverte et de spécification ne fait pas gagner de temps. Ça veut juste dire que l’équipe se rendra compte plus tard, et à plus gros prix, qu’elle a construit le mauvais produit.

La rapidité individuelle ne se traduit pas automatiquement par la production de l’équipe

La plupart des outils d’IA actuels permettent à un ingénieur d’aller plus vite sur sa propre machine. Les gains sont réels. Mais ils restent cantonnés à cet ordinateur portable.

En testant les outils concurrents, Kateryna a remarqué que : « Utiliser l’IA, c’est un processus très solitaire, et on n’en est pas encore au point où les équipes peuvent s’en servir de manière fluide. » 

Ce manque de collaboration était présent dans tous les outils que l’équipe a évalués. Un ingénieur met en place une configuration : des invites personnalisées, des compétences optimisées, un fichier de contexte soigneusement entretenu. Cette configuration fonctionne bien pour lui, mais pour personne d’autre, car personne d’autre ne peut la voir. S’il part, comme le fait remarquer Fabien, « tout est perdu ».

C’est un problème structurel. Les compétences, les invites, la mémoire de l’agent et le contexte partagé qui rendent une configuration d’IA efficace restent personnels jusqu’à ce qu’ils soient délibérément transférés dans une couche partagée que toute l’équipe peut voir et exploiter. Tant que ça n’est pas fait, la rapidité individuelle crée un problème de coordination plutôt qu’un gain de productivité pour l’équipe.

Voici les problèmes concrets qui surviennent lorsque l’IA reste sur des machines individuelles :

• La traçabilité disparaît. Quand un humain et plusieurs agents ont chacun modifié un bout de code à travers plusieurs outils, comprendre comment il s’est retrouvé en production devient un véritable travail d’archéologue. Un processus partagé et consigné résout ce problème de par sa conception.
• La validation devient un goulot d’étranglement. Si seule la personne qui a lancé les agents peut approuver l’étape suivante, l’avantage en termes de vitesse des agents parallèles s’effondre dès le premier contrôle humain. La validation doit être répartie au sein de l’équipe, et non pas être du ressort d’une seule personne.
• Les coûts sont invisibles. Les équipes qui utilisent des abonnements individuels n’ont aucune visibilité sur ce que l’IA dépense réellement par fonctionnalité, par processus ou par équipe. La facture arrive à la fin du mois. À ce moment-là, les décisions qui l’ont générée sont prises depuis longtemps.

Le code, c’est toujours le même boulot. C’est juste l’auteur qui a changé.

La dernière étape, et la plus cruciale, est celle que la plupart des équipes gèrent le moins bien.

• La responsabilité ne change pas. Fabien le dit sans détour : « Quand tu demandes à un LLM d’écrire une ligne de code, la responsabilité n’incombe pas au LLM. C’est à toi qu’elle revient. » Symfony est resté maintenable pendant plus de vingt ans parce que chaque ligne, peu importe qui l’a écrite, a été révisée en gardant ça à l’esprit. Le fait qu’un agent écrive le code ne change rien à cette obligation.
• La révision sert à détecter les changements. La vérification syntaxique ligne par ligne est de plus en plus souvent effectuée par un modèle. Ce qu’apporte un humain, c’est le bon goût. Comme le dit Fabien : « Les LLM n’ont pas de bon goût. Tu obtiens quelque chose qui est tout au plus moyen. Tu ne veux rien de moyen. » Le bon goût, c’est le jugement qui distingue le code qui passe les tests de celui qui aura encore du sens dans deux ans. Ça ne peut pas être délégué à l’agent qui a écrit le résultat.
• La confiance se mérite, elle ne s’accorde pas. Au début de tout processus, des contrôles humains sont prévus à chaque étape importante, non pas parce qu’on ne peut pas faire confiance aux agents en principe, mais parce que la confiance dans ce processus spécifique n’a pas encore été établie. À mesure que le processus prouve son bon fonctionnement, ces contrôles sont levés un par un. L’autonomie est réelle, mais elle s’acquiert par des preuves, elle n’est pas activée par une simple politique.
• « Terminé » signifie que ça marche, pas simplement que ça a été intégré. La boucle de rétroaction qui clôt la révision n’est pas « la compilation a réussi ». Les environnements de test fonctionnant sur une copie de l’infrastructure, des services et des données similaire à celle de production changent la signification de « terminé ». Un chef de produit peut vérifier si la fonctionnalité correspond à ce qu’il a spécifié. Un designer peut voir si l’interface est cohérente. Une régression de performances est détectée avant la mise en production, et non lors d’une révision post-incident.

Le cycle complet

Les trois étapes ci-dessus ne constituent pas une méthode en cascade. Elles sont interdépendantes. Une intention claire crée le contexte qui rend le résultat produit par l’agent digne d’être revu. Une bonne révision, combinée à une boucle de rétroaction qui teste dans des conditions réelles, est ce qui instaure la confiance permettant de réduire progressivement la supervision humaine. Chaque étape dépend de la précédente.

Les équipes qui y parviennent ne sont pas celles qui ont les meilleurs modèles ou les ingénieurs les plus rapides individuellement. Ce sont celles qui considèrent l’ensemble du cycle de vie du développement comme un système, où la découverte, le contexte, la collaboration, la révision et une véritable boucle de rétroaction fonctionnent tous ensemble.

 L’IA a accéléré la partie centrale de ce système. Le reste demande toujours autant de travail qu’avant.

À quoi ça ressemble en pratique ?

C’est exactement le problème qu’Upsun Dispatch™ a été conçu pour résoudre.

Au lieu de confier des agents à des ordinateurs portables individuels où leur production, leur coût et leur contexte sont invisibles pour le reste de l’équipe, Upsun Dispatch exécute les processus dans une couche partagée que toute l’équipe peut voir et faire fonctionner. Chaque action effectuée par un humain ou un agent est enregistrée et traçable. Le coût est visible pour chaque processus avant le début de l’exécution, et non pas découvert à la fin du mois.

Des contrôles humains sont mis en place à chaque étape importante dès le début. À mesure que le processus spécifique fait ses preuves, ces contrôles sont levés un par un. L’autonomie se construit sur la base de preuves, pas d’hypothèses. Et quand Upsun Dispatch fonctionne en parallèle avec Upsun Cloud, chaque modification bénéficie d’un environnement de test : une copie fidèle à la production de l’infrastructure, des services et des données. Ainsi, « terminé » signifie que l’équipe peut voir que ça fonctionne, pas seulement que la compilation a réussi.

Du coup, la rapidité que l’IA apporte à chaque individu commence à devenir un atout sur lequel toute l’équipe peut s’appuyer. 

• Tu es nouveau ici ? Lis l’introduction à Upsun Dispatch.
• Tu veux contribuer à son développement ? Postule pour rejoindre la première promotion de partenaires de conception.