Génération de code assistée

Comment ça marche

Un modèle entraîné sur des milliards de lignes de code sait écrire du code à partir d’une description : une fonction, un script, une page, une application. Intégré dans un agent, il peut aussi l’exécuter, lire les erreurs, corriger, et recommencer jusqu’à ce que ça marche. La génération de code assistée, c’est cette boucle, pilotée par un humain qui décrit, relit et décide.

La méthode qui donne des résultats durables tient en trois temps. Spécifier : décrire précisément ce que l’outil doit faire, cas par cas, y compris les exceptions. Tester d’abord : faire écrire les tests qui vérifient ces cas avant le code, pour que l’agent ait un objectif vérifiable. Relire : vérifier que le code fait ce qui était demandé, et seulement ça, sans faille évidente. Sans ces trois temps, on obtient vite beaucoup de code, et lentement un outil fiable.

Un exemple concret

1. Jour 1, spécification avec l’agent : la trésorière décrit le besoin. L’agent pose des questions : formats des exports bancaires, règles de rapprochement, que faire des écarts. Le résultat est un document de deux pages, relu par la trésorière.
2. Jour 2, tests puis code : l’agent écrit 24 tests à partir de la spécification, dont les cas limites (virement en deux fois, libellé tronqué, doublon). La trésorière les relit : trois cas ajoutés. Puis l’agent écrit l’outil jusqu’à ce que tous les tests passent.
3. Jour 3, revue et mise en place : un bénévole qui sait lire du code relit le résultat. Il demande deux simplifications. L’outil est mis dans Git, avec un README, et installé sur l’ordinateur de la trésorerie.
4. Six mois plus tard : la banque change le format de ses exports. La trésorière décrit le nouveau format à l’agent, les tests signalent ce qui casse, l’agent adapte. Une heure.

Le code représente environ 600 lignes. La trésorière n’en a lu aucune. Elle a lu la spécification et les tests, et c’est ce qui lui a donné confiance.

Ce que ça change pour une équipe

• Le coût de construction d’un outil s’effondre. Ce qui demandait un prestataire et des semaines se fait en jours, pour les outils de taille modeste.
• Le besoin devient la compétence clé. Savoir ce qu’on veut, le décrire et le vérifier compte plus que savoir coder.
• La maintenance change de nature. Un outil avec spécification et tests se fait évoluer par un agent, sur description. Sans, il se fige.
• Il faut quand même un relecteur. Quelqu’un qui comprend le code, au moins dans les grandes lignes, pour la revue et les questions de sécurité.

Les limites et les erreurs fréquentes

• Générer sans spécifier. L’agent remplit les blancs avec ce qui lui semble logique. Ce n’est pas forcément votre logique.
• Sauter les tests. « Ça marche » sur trois essais manuels n’est pas « ça marche ». Les tests écrits avant sont le contrat.
• Laisser grossir sans relire. Un outil de 600 lignes devient 6 000 lignes en six mois, et plus personne ne sait ce qu’il contient. La revue à chaque changement évite ça.
• Négliger la sécurité. Mots de passe en clair, accès trop larges, entrées non vérifiées : les points que les modèles oublient le plus. La revue les cherche en premier.