Le développement agentique

L'arrivée fulgurante de l'IA dans nos vies pose évidemment de nombreux défis, auxquels nos sociétés devront rapidement apporter des réponses.

Mais quoi qu'on en pense, c'est désormais une réalité à laquelle il faut s'adapter pour en tirer le meilleur : le gain de productivité qu'elle apporte est tel qu'un retour en arrière semble impossible.

Pour l'ingénieur logiciel, l'IA change radicalement l'approche du développement.

Certains y sont réfractaires, car l'IA dénature en quelque sorte le métier en rendant caduque l'écriture manuelle du code. Pour ma part, mes compétences d'architecte et d'organisation y trouvent toute leur place.

En prenant en charge l'écriture mécanique du code, l'IA me permet en effet de consacrer l'essentiel de mon temps aux tâches conceptuelles à forte valeur ajoutée.

Ce qui change concrètement

Par développement agentique, j'entends deux niveaux d'usage de l'IA : le codage informel (« vibe coding »), où l'on ajuste un prompt au coup par coup jusqu'à obtenir le résultat désiré, et l'ingénierie agentique^{[1] [4]}, qui structure le travail par des consignes, des outils et des tests, et dans laquelle le développeur, tel un chef d'orchestre, dirige, encadre et valide les productions des agents.

Les deux approches sont complémentaires : la première convient aux ajustements ponctuels et précis (par exemple pour affiner une interface), la seconde permet de piloter le projet dans son ensemble. C'est ce second niveau qui fait l'objet de la suite de cet article.

Pour le développeur

• Un accès immédiat à des connaissances et compétences transversales. Savoir manier un outil importe désormais moins que savoir ce que l'on veut en tirer et faire preuve de créativité.
• Du temps libéré pour la conception : pendant que l'agent implémente les tâches que je lui confie, je vérifie le travail réalisé (code et tests) et je planifie les chantiers suivants. Mon temps se partage ainsi presque entièrement entre les casquettes d'architecte et de product owner.

Pour le projet

• Une vitesse d'implémentation incomparable : un agent produit du code beaucoup plus vite qu’un humain, en particulier pour les tâches répétitives ou clairement spécifiées (sans toutefois dispenser du cadrage ni de la validation du résultat).
• Un produit plus abouti : on peut prototyper et comparer rapidement plusieurs pistes avant de trancher, puis peaufiner les fonctionnalités pour un résultat mieux pensé et plus ergonomique.
• Ce qui était négligé devient la norme : les tests, la documentation, l'architecture, les conventions et la cohérence du code — trop souvent sacrifiés, faute de temps — peuvent désormais être mis en place et tenus à jour en continu.
• Une codebase plus accessible : un agent lit la documentation et appréhende le code existant bien plus vite qu'un nouveau développeur, qui a besoin de temps pour se l'approprier avant de pouvoir travailler efficacement. Les nouveaux arrivants deviennent productifs plus rapidement et le projet dépend moins des développeurs seniors « piliers », dont le savoir était jusqu'ici rarement formalisé.

C'est à mes yeux le gain principal : libéré de l'écriture du code, on se concentre enfin sur ce qui fait réellement la qualité et la fiabilité du produit.

Les points de vigilance

Ces gains ont évidemment des contreparties : l'IA apporte aussi son lot de problèmes inédits et une complexité d'un genre nouveau.

Garder la maîtrise du projet

Déléguer l'écriture du code ne signifie pas s'en désintéresser. Laisser les agents totalement libres, c'est perdre la vision de ce que devient la codebase — et découvrir trop tard qu'elle repose sur de mauvais choix ou sur une architecture bancale.

Il faut donc tenir les rênes : comprendre ce que fait l'IA, connaître le fonctionnement et l'organisation générale du code, pour éviter que le projet ne dérive au fil des itérations. La maîtrise porte alors moins sur chaque ligne de code que sur les objectifs, l'architecture et les règles du projet.

Quelqu'un doit néanmoins relire le code produit pour le corriger si nécessaire, or une relecture exhaustive est longue et fastidieuse : l'enjeu est de trouver le juste équilibre entre rapidité et rigueur.

Des résultats dépendants des consignes...

La qualité du code produit reste très dépendante des consignes données : il faut soigner ses prompts ainsi que les guidelines du projet, pour que l'agent suive les bonnes pratiques et la structuration du code attendues.

L'IA a par exemple tendance à réinventer des solutions ad hoc au lieu de réutiliser ou d'adapter l'existant. Il faut donc le lui demander explicitement si l'on veut conserver une codebase cohérente.

... et de la dette technique

Elle suivra également le style ou les pratiques qu'elle trouvera dans la codebase, donc si celle-ci contient du code legacy ou peu qualitatif, elle en reproduira et amplifiera les défauts !

Il faut donc la cadrer avec des guidelines explicites et les garde-fous nécessaires pour garantir la qualité du code généré.

Développeur : de l'exécution au pilotage

Le philosophe Bernard Stiegler désigne par « prolétarisation »^[2] la perte d'un savoir lorsqu'il est transféré de l'humain vers une machine ou un système technique. Elle ne touche pas seulement le savoir-faire de l'artisan devenu ouvrier, mais aussi le savoir concevoir des ingénieurs et des décideurs, lorsqu'ils s'en remettent à des systèmes qu'ils ne comprennent plus — réduits à de simples exécutants, dépossédés de la décision et de la responsabilité méthodologique.

Le développeur n'est pas (encore) remplacé par la machine, mais pour ne pas être dépossédé de son savoir conceptuel, il doit changer radicalement sa façon de travailler : il s'agit désormais de construire le cadre et le workflow qui permettent de piloter et de contrôler les agents. C'est précisément ce cadre qui répond aux points de vigilance évoqués plus haut.

Un harnais de sécurité renforcé

Dans ce mode de travail, on n’écrit presque plus le code soi-même : il faut définir précisément ce que les agents doivent faire, avec des spécifications claires et des tests rigoureux, pour ne pas avoir à reprendre continuellement le code produit. Le TDD (développement piloté par les tests) prend ici tout son sens : les tests, validés par le développeur, décrivent le comportement attendu avant l'implémentation, puis le vérifient automatiquement.

Typage strict, analyse statique, linters, intégration continue... ces outils équipaient déjà les projets les plus matures, mais ils deviennent indispensables car ils réduisent significativement la part de relecture humaine — et sont désormais rapides à mettre en place (avec un agent !).

Des consignes précises

Il faut également travailler ses prompts pour augmenter la précision des demandes, et surtout formaliser les guidelines du projet : architecture du code, conventions et bonnes pratiques à suivre, réutilisation de l'existant...

Versionnées comme le code lui-même, elles évitent de réexpliquer le contexte ou la marche à suivre à chaque demande — et forment une documentation précieuse, aussi utile aux développeurs qu'aux agents.

Une architecture lisible

Une codebase bien découpée — modules cohésifs, couches clairement délimitées, dépendances explicites — offre à l'agent un contexte restreint, facile à appréhender et à reproduire, ce qui rend son travail plus fiable.

L'IA agit en réalité comme un amplificateur : elle tire vers le haut un projet bien structuré, mais accélère la dégradation d'un projet qui ne l'est pas.

Les principes présentés dans mon guide Comprendre l'Architecture logicielle s'appliquent ici pleinement.

Une relecture proportionnée aux enjeux

Pour trouver ce juste équilibre, tout le code ne mérite pas la même attention :

• survoler le code trivial ou mécanique, déjà couvert par les tests ;
• relire en détail ce qui est critique : domaine métier, sécurité, choix structurants ;
• compléter par des audits réguliers (qualité, sécurité, cohérence).

Des agents plus autonomes

L'objectif est de rendre les agents les plus autonomes possible, en réduisant leurs questions et les corrections à apporter à leur travail. Plus le cadre sera précis, moins l'agent sollicitera le développeur.

Cette autonomie ouvre la voie à de véritables équipes d'agents aux rôles distincts : l'un implémente, un autre relit, un troisième audite la sécurité ou la cohérence du code... Une partie de la relecture peut ainsi être déléguée, à condition que le développeur en fixe les règles et garde la main sur les points critiques.

Conclusion

Le métier ne disparaît pas, il se déplace : de l'écriture du code vers la conception, la définition du cadre et la validation. Les compétences en architecture et en conduite de projet ne sont plus accessoires : elles deviennent centrales.

Stiegler voyait dans toute technique un pharmakon^[3], à la fois poison et remède selon l'usage qui en est fait. L'IA n'y échappe pas : poison si le développeur lui délègue aussi la conception et les décisions, remède si elle le libère de l'écriture mécanique pour qu'il se consacre à ce qui fait la qualité d'un logiciel.

Une question reste toutefois ouverte pour les développeurs juniors et les étudiants : comment acquérir les bases d'un métier dont l'IA prend en charge la partie la plus visible ?

Savoir lire et évaluer du code reste indispensable pour garder la maîtrise du code produit, mais il est essentiel de comprendre que le métier a changé, pour orienter dès maintenant sa progression vers l'architecture, la conception et le pilotage de projet — là où se trouve désormais la valeur du développeur.