Comment nous développons nos logiciels avec des agents IA (sans leur laisser les clés)

Chez SyNode-IT, nous développons plusieurs logiciels en parallèle, dont Phisheur et VisuMail. Les agents IA capables d'écrire du code nous font gagner un temps précieux, mais laisser une IA modifier seule une application en production serait une très mauvaise idée. Notre réponse s'appelle Hermes : un orchestrateur qui fait travailler des agents IA dans un cadre strict, où chaque modification est vérifiée, tracée et réversible.

D'abord, mesurer les modèles

Avant de distribuer des rôles, nous avons mesuré les modèles que nous pouvions faire tourner sur nos propres machines : temps de chargement, temps de réponse, débit de génération, et surtout capacité à appeler des outils. Un petit modèle très rapide est parfait pour une tâche de surveillance légère, mais inutile comme agent s'il ne sait pas lire un fichier ou lancer une commande. C'est cette capacité, plus que la vitesse, qui décide de la place d'un modèle dans le système.

Des agents, chacun dans son rôle

• Les développeurs prennent une tâche et la réalisent. Il n'y en a qu'un seul par projet, pour éviter que deux agents se marchent dessus.
• Les rapporteurs font le point sur l'avancement et signalent ce qui bloque.
• Les surveillants veillent en continu sur l'état des projets et des services.

Nos premières versions faisaient tourner de nombreux agents planifiés, chacun travaillant dans son coin : ils se répétaient, proposaient les mêmes changements et produisaient surtout du bruit. Un seul agent qui écrit, et des rôles bien séparés autour de lui, s'est révélé à la fois plus sûr et plus productif.

Une règle complète cette organisation : ce qu'un script peut vérifier n'est pas confié à une IA. Savoir si un service répond, si la base est joignable ou si la sauvegarde a tourné relève d'un contrôle déterministe, plus fiable et moins coûteux qu'un modèle de langage.

Le parcours d'une modification

Aucune modification ne part directement en production. Chacune suit le même circuit :

• L'agent travaille dans un espace isolé, sur une branche dédiée, sans toucher à la version en service.
• Il réalise un seul incrément, volontairement limité.
• Les tests du projet sont lancés en entier. Tout nouveau test est d'abord écrit pour échouer, puis le code est corrigé jusqu'à ce qu'il passe.
• Les changements sont analysés, notamment pour vérifier qu'aucun secret ne s'y est glissé.
• Une demande de fusion est ouverte sur notre forge Git.
• Une revue technique indépendante doit approuver la version exacte du code, et l'intégration continue doit être au vert.
• Après la fusion, l'application est redéployée puis contrôlée deux fois.
• Si le service ne répond pas correctement, Hermes revient automatiquement à la version précédente.

Une tâche n'est considérée comme terminée qu'une fois la modification fusionnée et le service vérifié en bonne santé.

Pourquoi la revue doit être indépendante

Faire relire le code d'un modèle par un modèle de la même famille ne garantit pas grand-chose : il partage ses angles morts et validera volontiers les erreurs qu'il aurait lui-même commises. Un relecteur de ce type reste utile comme premier filtre (chemins de fichiers, imports, syntaxe), mais pas comme juge. C'est pour cela que la revue porte sur la version exacte du code, qu'elle est indépendante de l'agent qui l'a écrit, et qu'elle s'ajoute aux tests au lieu de les remplacer.

Autre point appris à nos dépens : un refus doit nourrir la suite. Quand une modification est rejetée, la raison du rejet revient à l'agent. Sans ce retour, il propose à nouveau la même erreur, et le système perd son seul signal d'apprentissage.

Les lignes rouges

Certaines décisions restent humaines, sans exception. Une migration de données destructive, un changement de secrets, une opération irréversible ou une modification qui sort du périmètre prévu exigent une revue humaine et ne sont jamais fusionnées automatiquement. Pour Phisheur, qui touche à la sécurité de nos clients, l'activation des livraisons reste soumise à une validation humaine.

Ce que nous en avons appris

• La valeur est dans le cadre, pas dans l'IA : ce sont les tests, les revues et les contrôles de santé qui rendent le résultat fiable.
• Les petits pas vont plus vite : des incréments limités sont plus faciles à vérifier et à annuler.
• Un agent doit prouver qu'il gagne sa place : nous fixons dès le départ le critère qui fera supprimer un rôle s'il produit plus de bruit que de modifications utiles.
• La documentation s'écrit aussi pour les agents : ils la lisent autant que nous, et un point d'entrée clair leur dit quoi lire et dans quel ordre.
• On industrialise, on ne copie pas : les scripts et modèles sont communs à tous les projets et simplement paramétrés pour chacun.
• On grandit par étapes : un nouveau projet ne rejoint Hermes que lorsque des critères précis sont remplis.

Et pour vous ?

Cette rigueur est celle que nous appliquons aux systèmes de nos clients : des changements testés, tracés et réversibles. Et si vous réfléchissez à utiliser l'IA dans votre entreprise, nous pouvons vous aider à le faire avec les bons garde-fous.