Livrer un produit avec des agents IA : ce qui change vraiment

Je travaille avec des agents IA sur la quasi-totalité de mes missions depuis plus d'un an. Non pas parce que c'est à la mode, mais parce que ça change réellement ma vitesse de livraison, à condition de ne pas se raconter d'histoires sur ce que ça remplace. Ça ne remplace pas le jugement d'ingénierie. Ça déplace où ce jugement s'exerce.

Le déplacement, concrètement

Avant les agents, une grande partie de mon temps allait dans l'écriture de code : taper les lignes, gérer la plomberie, répéter des patterns déjà connus. Avec un agent qui écrit vite et de manière plausible, ce temps-là s'effondre. Mais un nouveau goulot d'étranglement apparaît immédiatement : si la spécification est floue, l'agent produit du code qui compile, qui a l'air raisonnable, et qui résout un problème légèrement différent de celui qu'on avait en tête. Le travail ne disparaît pas, il se déplace en amont : vers la clarté de ce qu'on demande, vers l'architecture qui contraint les choix possibles, et en aval : vers la vérification de ce qui a été produit.

Concrètement, ça veut dire que je passe plus de temps qu'avant à découper un problème en tâches petites et vérifiables, et moins de temps à taper du code moi-même. Ça veut aussi dire que je passe plus de temps en revue, parce qu'un code plausible mais faux est plus dangereux qu'un code qui ne compile pas : il passe les yeux, il passe parfois les tests existants, et casse discrètement autre chose.

Comment je structure le travail

Le principe qui fonctionne, c'est de traiter chaque tâche comme un contrat vérifiable avant de la confier à un agent. D'abord un plan : qu'est-ce qu'on construit, pourquoi, quelles sont les étapes. Ensuite, découper ce plan en tâches suffisamment petites pour qu'une seule chose puisse mal se passer à la fois, et suffisamment précises pour qu'on sache à quoi ressemble le succès avant de commencer. Puis, les tests comme porte d'entrée : pour une fonctionnalité ou une correction, écrire d'abord ce qui prouve que ça marche (ou que le bug est reproduit), avant de laisser l'agent implémenter. Enfin, la revue : je lis le diff, je ne le survole pas, parce que c'est le seul moment où le jugement humain intervient réellement sur ce qui va en production.

Ce cycle, plan puis tâches vérifiables puis tests comme porte puis revue, n'est pas nouveau en soi : c'est de l'ingénierie logicielle sérieuse. Ce qui change avec les agents, c'est la vitesse à laquelle on peut le parcourir, et donc l'exigence de le parcourir vraiment, à chaque tour, plutôt que de le sauter parce qu'on est pressé.

Ce qui casse si on ne fait pas attention

Trois choses cassent régulièrement chez les équipes qui utilisent des agents sans discipline. La perte de contexte d'abord : un agent qui travaille sur une tâche longue oublie ou déforme des contraintes posées plus tôt, et produit une solution cohérente en apparence mais qui contredit une décision prise vingt échanges plus tôt. Le code plausible mais faux ensuite : la caractéristique la plus dangereuse d'un LLM, c'est qu'il ne rédige jamais un code qui a l'air incertain. Il a la même confiance apparente qu'il ait raison ou tort. Les régressions silencieuses enfin : un agent qui corrige un bug local peut, en chemin, modifier un comportement adjacent que personne ne testait, et ça ne remonte que des semaines plus tard.

La parade à ces trois risques est la même : des tâches petites, des tests qui couvrent le comportement avant qu'on y touche, et une revue humaine qui ne se contente pas de vérifier que ça compile.

Ce que ça change pour un client

Pour un client, ce que ça signifie n'est pas « moins cher parce que moins d'heures humaines ». C'est plus rapide sans perte de qualité, parce que le temps gagné sur l'écriture est réinvesti dans la spécification et la vérification, pas supprimé. La vitesse ne vient pas du fait de sauter des étapes, elle vient du fait que les étapes qui comptaient déjà (comprendre le besoin, découper le travail, vérifier le résultat) se répètent plus vite avec un collaborateur qui ne fatigue pas sur la partie mécanique.

Je ne vends pas une promesse d'automatisation magique. Je vends un processus d'ingénierie plus rapide, où je reste le point de décision sur l'architecture, les compromis produits et la qualité finale. C'est cette discipline, et pas les agents eux-mêmes, qui fait la différence entre un projet livré vite et bien, et un projet livré vite et regretté six mois après.