Les agents IA qui écrivent du code ne sont plus une curiosité. La vraie question, pour une entreprise, n’est plus « est-ce que ça marche ? » mais « est-ce que je peux les laisser travailler sans moi, et le vérifier le lendemain matin ? »

Les nuits du 11 et du 12 octobre 2026, nous avons fait tourner chez WebTrafic une vingtaine de sessions d’agents IA en parallèle, sur deux machines : un serveur et un poste de travail. Au matin, 21 comptes rendus de session nous attendaient. Voici l’organisation qui rend cela possible, les incidents que nous avons eus, et ce que nous en avons changé.

Le principe : une session, un chantier, un compte rendu

Chaque session est un agent IA lancé en mode non interactif (un mode « headless », sans conversation : l’agent reçoit ses consignes et rend son résultat). Une session principale, que nous pilotons, prépare les consignes puis lance les autres. Chaque session reçoit :

  • un seul chantier, avec un périmètre écrit : par exemple « retirer une option de cache de la CI sur tous les dépôts » ou « préparer la version 0.2.0 de notre outil d’audit » ;
  • sa propre copie de travail du code. Nous utilisons les worktrees de Git : deux agents ne travaillent jamais dans le même dossier, donc ne s’écrasent jamais ;
  • une liste d’interdits identique pour tous ;
  • une obligation de sortie : un compte rendu daté, déposé par une proposition de modification (une « pull request »), avec ce qui est fait, ce qui est en cours, ce qui bloque, et les gestes exacts attendus d’un humain.

Le point clé est le relais. Aucune session n’écrit dans le journal commun ni dans le tableau de pilotage. Elles ne déposent que leur propre compte rendu, et c’est la session principale qui consolide au matin. Vingt agents qui écrivent dans le même fichier, c’est vingt conflits. Vingt comptes rendus séparés, c’est une lecture d’une demi-heure.

Les garde-fous : ce qu’un agent n’a jamais le droit de faire seul

La liste tient en une ligne, et elle est la même pour toutes les sessions : pas d’e-mail envoyé, pas de publication, pas de paiement, pas de compte créé, pas de mot de passe saisi, pas de suppression de données, pas de nouvelle dépense. Un agent prépare des brouillons ; un humain décide.

Le reste est autorisé, et c’est ce qui rend la nuit productive : analyser le code, corriger, tester, proposer et fusionner des modifications quand tous les contrôles automatiques sont verts sur la dernière version du code. Sans réécriture forcée de l’historique, sans contournement des contrôles.

S’ajoutent des garde-fous de ressources, parce que vingt agents partagent les mêmes machines :

  • pas plus de trois propositions de modification en contrôle à la fois par session, pour ne pas saturer le serveur de CI ;
  • un sémaphore sur le serveur de CI, qui admet au plus 16 tâches simultanées et refuse les suivantes après une attente bornée ;
  • un seuil d’espace disque sous lequel une session s’arrête au lieu de construire.

Les preuves : une valeur observée, jamais une conclusion

Un agent IA rédige très bien. C’est précisément le danger : un compte rendu peut affirmer « tests verts » sans qu’aucun test n’ait tourné. Notre règle est donc stricte : une preuve est une commande et sa sortie, pas une phrase.

Concrètement, dans les comptes rendus de ces deux nuits :

  • un audit complet de nos sites est relancé avant et après correction. Selon le relevé brut, il passe de « 5 390 ok, 22 ko » à « 5 410 ok, 2 ko », après 8 propositions de modification sur 7 sites, chacune vérifiée en ligne ;
  • chaque contrôle de sécurité prouve d’abord qu’il détecte. L’outil de recherche de secrets est lancé sur un faux jeton planté exprès : il doit répondre « 1 fuite trouvée » avant que son « aucune fuite » sur le vrai code ait une valeur ;
  • les tests des garde-fous sont vérifiés par mutation : on retire volontairement le garde-fou, le test doit passer au rouge (« not ok 11 the maintenance lock refuses new jobs »), puis on remet le code.

Cette exigence a un effet secondaire précieux : elle rend les erreurs de l’agent visibles. Une nuit, un sous-agent a signalé un script comme « syntaxiquement faux ». Il l’avait vérifié avec le mauvais interpréteur. Parce que la règle impose de revérifier avant d’agir, rien n’a été « corrigé » à tort.

Ce qui a mal tourné, et ce que nous avons changé

Une nuit sans incident n’existe pas. Ce qui compte, c’est que chaque incident devienne une règle écrite.

1. Des brouillons fusionnés par l’automate

Nous avons un automate de maintenance qui finalise et fusionne les propositions de modification restées en suspens. Il ne s’arrête que devant une étiquette précise. Deux fois, les 11 et 12 octobre, une session a ouvert un brouillon sans cette étiquette, en pensant que « brouillon » suffisait à le protéger. L’automate l’a passé en « prêt », puis fusionné, avant la relecture prévue.

Conséquences limitées dans les deux cas, mais la leçon est nette. Désormais, l’étiquette de blocage est posée dès la création de tout brouillon qui attend une décision humaine, et la consigne le dit en toutes lettres.

2. Des échecs de CI qui n’en étaient pas

Plusieurs propositions de modification restaient rouges depuis le matin. Sur un échantillon de 30 tâches en échec, le compte rendu en relève 27 qui n’étaient pas des erreurs de code, mais des refus du sémaphore : « serveur occupé ». Personne ne les relançait.

Correctif : le superviseur relance lui-même une tâche si et seulement si tous ses échecs sont ce refus précis, au plus trois fois par version, à quinze minutes d’intervalle. Selon le compte rendu, 7 propositions ont été relancées une fois chacune, et toutes sont passées au vert ensuite.

3. Un dossier temporaire partagé saturé

Sur le serveur, toutes les sessions écrivaient leurs constructions dans le même dossier temporaire, limité à 3,8 Go. Il s’est rempli deux fois. La session concernée a déplacé ses constructions dans son propre espace et vidé un cache régénérable. La règle générale en découle : chaque agent a son propre espace, et nettoie ce qu’il a créé en partant.

4. Des propositions toujours en retard sur la version principale

Quand vingt sessions fusionnent dans la même nuit, une proposition validée devient vite « en retard » : la version principale a bougé entre-temps, et la protection exige une branche à jour. Correctif : les propositions liées d’une même session sont regroupées dans une seule branche d’intégration, fusionnée une fois, plutôt qu’une à une.

Ce que ça change pour une entreprise

Faire travailler des agents IA la nuit n’est pas une question d’outil. C’est une question d’organisation écrite :

  1. Découpez : un agent, un chantier, un périmètre. Un agent à qui l’on confie « améliore le site » ne peut pas rendre de compte précis.
  2. Écrivez les interdits une fois pour toutes, et faites-les respecter par la machine quand c’est possible (étiquettes, sémaphore, contrôles obligatoires), pas seulement par la consigne.
  3. Exigez des preuves, pas des résumés. Un compte rendu sans commande ni sortie ne vaut rien.
  4. Gardez l’humain sur les décisions irréversibles : envoyer, publier, payer, supprimer.

C’est la méthode que nous appliquons aux agents IA que nous mettons en place pour nos clients et à leurs automatisations ; nos études de cas montrent ce qu’elle produit, chiffres à l’appui. Si vous voulez savoir ce qu’elle donnerait dans votre activité, parlons-en.