Le futur du développement : un code que les agents IA peuvent comprendre

Pendant vingt ans, la question « ce code est-il lisible ? » voulait dire « un autre développeur le comprendra-t-il dans deux ans ? ». Elle en a gagné une seconde, et elle change plus de choses qu'il n'y paraît : un agent IA peut-il le comprendre, le modifier et prouver qu'il ne l'a pas cassé ?

Le lecteur a changé, les critères aussi

Un développeur humain qui découvre un projet compense les manques. Il devine l'intention derrière un nom approximatif, demande au collègue d'à côté, retrouve la logique en lisant l'historique des commits. Il arrive avec un contexte que le code ne contient pas.

Un agent n'a que ce qu'on lui donne. Il lit le code, les commentaires, les tests et la documentation, et rien d'autre. Tout ce qui n'est écrit nulle part n'existe pas pour lui. Un projet qui tenait debout grâce à la mémoire de son auteur devient un projet qu'un agent modifie à l'aveugle.

C'est une bonne nouvelle déguisée : les qualités qui rendent un code exploitable par une machine sont exactement celles qui le rendaient déjà maintenable par une équipe. Nommer juste, séparer les responsabilités, écrire pourquoi et pas seulement comment. Rien de neuf, sauf que la négligence coûte désormais immédiatement.

La clarté se mesure, elle ne se décrète pas

Trois choses pèsent plus que les autres quand un agent travaille sur un projet.

Les noms. Une fonction appelée process oblige à lire son corps entier pour savoir ce qu'elle fait. Une fonction appelée calculateVatForEuropeanCustomer se comprend sans être ouverte. L'agent raisonne sur les noms avant de raisonner sur le code, exactement comme un humain pressé.

Les frontières. Une architecture où la règle métier est mêlée à la base de données et à l'affichage oblige à tout charger pour modifier une ligne. Quand le domaine est isolé, l'agent travaille sur un périmètre réduit, et une erreur reste locale. Séparer les couches n'était pas qu'un confort d'architecte, c'est devenu une condition de travail.

Les commentaires qui expliquent une décision. Un commentaire qui paraphrase le code est du bruit. Un commentaire qui dit « cette valeur est codée en dur parce que le fournisseur renvoie une date invalide une fois sur mille » est irremplaçable : cette information n'est nulle part ailleurs, et sans elle la prochaine modification réintroduit le bug.

La documentation devient une interface, pas une corvée

Un fichier qui décrit la structure du projet, ses conventions et ses pièges connus n'est plus un document mort que personne n'ouvre. C'est ce que l'agent lit en premier, et ce qui détermine la qualité de tout ce qu'il produira ensuite.

Ce qui mérite d'y figurer est précis : où vit quoi, quelles commandes lancer, quelles règles ne se devinent pas. Les pièges comptent autant que les règles. « Ne jamais modifier ce dossier à la main, il est généré » évite une catégorie entière d'erreurs, humaines comme automatiques.

Et cette documentation se maintient comme du code. Périmée, elle est pire qu'absente : elle oriente avec assurance dans la mauvaise direction.

Le vrai sujet : un système de vérification solide

C'est là que tout se joue, et c'est la partie que l'enthousiasme sur les agents oublie le plus souvent.

Un agent produit du code vraisemblable. Vraisemblable n'est pas correct. Il écrira une fonction qui compile, se lit bien, et se trompe sur un cas limite que personne n'a énoncé. Lui faire confiance sur la relecture seule est une méthode qui marche jusqu'au jour où elle ne marche plus, en production.

La réponse n'est pas de ralentir l'agent, elle est de rendre l'erreur détectable automatiquement. Une suite de tests qui couvre les parcours critiques transforme une intuition en verdict : ça passe ou ça ne passe pas. Un typage strict élimine une classe entière de fautes avant même l'exécution. Une analyse statique attrape ce que la relecture laisse filer. Une intégration continue qui refuse la fusion quand un test tombe ferme la porte pour de bon.

Formulé autrement : plus l'écriture est rapide, plus la validation doit être automatique. Un projet sans tests n'est pas neutre face aux agents, il est dangereux, parce qu'il accepte silencieusement tout ce qu'on lui donne.

Ce que ça change pour un projet que l'on commande

Si vous faites développer un site ou une application, ces exigences ne sont pas de la cuisine interne. Elles décident de ce que coûtera la suite.

Un projet clair, documenté et couvert par des tests pourra être repris et modifié rapidement, par un humain comme par un agent, y compris par un autre prestataire que celui qui l'a écrit. Un projet opaque restera cher à faire évoluer, et le restera d'autant plus que l'écart se creusera avec ceux qui ont fait l'effort.

Ce sont les questions à poser avant de signer : y a-t-il des tests automatisés, quelle part du code couvrent-ils, où est la documentation technique, et puis-je récupérer le tout si je change de prestataire. Les réponses en disent plus long qu'un argumentaire.

C'est la logique de notre travail sur l'architecture du code, et la raison pour laquelle le support et la maintenance font partie de chaque accompagnement : un code conçu pour être repris n'a de valeur que si quelqu'un le reprend réellement.