L'agent, c'est la force. Le harnais, c'est le contrôle.

24 septembre 2026 · par Amady

<p class="lead">Pourquoi les équipes de dev ont besoin d'un harnais, pas juste d'un agent</p>

On a tous essayé un agent.

On lui a donné une tâche. Il a écrit du code. Parfois bon, parfois pas.

Puis on a essayé de le mettre dans une vraie équipe. Et là, tout s'est compliqué.

Qui a lancé quoi ? Sur quel dépôt ? Avec quel accès ? Est-ce que quelqu'un a relu ? Est-ce que les tests ont tourné ? Est-ce que le résultat est quelque part, ou est-ce qu'il a disparu avec la session ?

Ces questions, personne ne se les posait il y a deux ans. Aujourd'hui, elles bloquent des équipes entières.

Le modèle n'est plus le problème

Pendant deux ans, la course a été au modèle. Le plus rapide, le plus précis, le plus grand contexte, le moins cher. Chaque mois apportait son lot d'annonces.

Aujourd'hui, la question a changé.

Les modèles se valent à peu près. Pas parfaitement : il y a des différences, des sensibilités, des forces. Mais pour 90 % des tâches de développement, n'importe quel modèle de milieu de gamme fait le travail.

Ce qui fait la différence, ce n'est plus ce qui écrit le code. C'est ce qui l'entoure.

Que peut-il lire ? Que peut-il modifier ? Quels outils peut-il utiliser ? Qui décide de ce qui est autorisé ? Où sont gardés les résultats ? Qui peut les voir ? Qui peut les arrêter ?

Un modèle sans réponse à ces questions n'est pas un agent. C'est un générateur de texte qui touche à des fichiers.

Le mot : harnais

Le mot existe, mais il est peu utilisé. C'est un mot du monde équestre.

Un harnais ne crée pas la force du cheval. Il la canalise, la dirige, la contrôle. Il transforme une puissance brute en un attelage utilisable. Sans harnais, un cheval reste un cheval : puissant, imprévisible, inutilisable pour tirer une charrue ou un carrosse. Avec un harnais, il devient un moteur.

En IA, un harnais, c'est exactement la même chose.

C'est tout ce qui transforme un modèle en agent utilisable :

Les outils qu'il peut appeler (fichiers, shell, API, recherche web)
La mémoire qu'il peut garder (session, contexte, historique)
Les permissions qu'il doit demander (avant d'écrire, avant de supprimer)
Les boucles qui le font travailler (jusqu'à ce que la tâche soit finie)
Les garde-fous qui l'arrêtent (limites de tours, plafonds de dépense, interdictions)

Claude Code a son harnais. Copilot a son harnais. Cursor a son harnais. Chaque CLI d'agent a le sien, plus ou moins riche, plus ou moins ouvert, plus ou moins documenté.

C'est ce qui fait qu'un même modèle peut être inutilisable dans un outil et excellent dans un autre. Le modèle ne change pas. Le harnais, si.

Mais aucun de ces harnais n'est un harnais d'équipe

C'est là que le problème commence.

Le harnais de votre CLI d'agent travaille pour vous. Il connaît votre machine, vos fichiers, votre session. Il est conçu pour un seul utilisateur, sur un seul poste, sur une seule tâche à la fois.

Ce qui veut dire qu'il ne sait pas :

Qui d'autre travaille sur le même dépôt
Qu'un collègue a déjà lancé une review sur la même MR
Qu'un agent planifié doit tourner sur un poste, pas sur cinq
Qu'un résultat doit être partagé avec l'équipe
Que deux personnes ne doivent pas payer deux fois pour le même travail

Ces questions ne sont pas techniques. Elles sont organisationnelles. Et aucun harnais individuel n'y répond, parce que ce n'est pas son rôle. Ce n'est même pas dans son périmètre.

C'est là que les équipes se cassent.

On a tous vu la scène : trois développeurs, trois sessions d'agent ouvertes, trois reviews lancées sur la même MR parce que personne ne savait que les autres l'avaient fait. Trois appels IA facturés. Trois commentaires postés sur la merge request. Trois rapports différents, avec trois notes différentes.

Ou pire : un agent planifié qui tourne sur trois postes à la fois, trois fois par jour, et qui consomme trois fois le budget prévu. Personne ne s'en aperçoit avant la fin du mois.

Ou encore : un développeur qui a fini son quota, qui attend le lendemain, alors qu'un collègue à côté a encore trois semaines de marge. Mais rien ne circule, parce que les sessions sont attachées à une machine, pas à une équipe.

Ces problèmes ne sont pas nouveaux. Ils sont juste invisibles tant qu'on travaille seul. Ils deviennent bloquants dès qu'on est trois.

Ce qu'un harnais d'équipe doit faire

Un harnais d'équipe, c'est la couche qui répond aux questions qu'un harnais individuel ignore. Il ne remplace pas le harnais du CLI : il l'encadre, le sécurise, le coordonne.

Concrètement, il répond à cinq questions :

1. Qui exécute ?

Une review automatique ne doit tourner qu'à un endroit. Un agent planifié doit avoir un exécutant désigné. Sinon, cinq postes allumés produisent cinq fois le même travail, cinq fois la même facture, cinq fois le même commentaire sur la MR.

Un harnais d'équipe tient un registre des exécutions. Il sait ce qui tourne, où, et par qui. Il évite les doublons. Il permet à un poste bloqué de passer la main à un autre.

2. Qui valide ?

Aucun merge automatique. Aucun push non relu. Les agents préparent, l'humain décide.

Cette règle ne doit pas être une promesse commerciale. Elle doit être portée par le code. Un agent ne doit pas pouvoir pousser, même si on le lui demande. Il ne doit pas pouvoir publier un commentaire, même si c'est écrit dans son prompt. La garantie doit être structurelle, pas déclarative.

Un harnais d'équipe, c'est ce qui rend cette garantie possible.

3. Où sont les résultats ?

Les sessions, les rapports, les règles, les vérificateurs vivent quelque part. Pas dans un terminal qui disparaît quand on ferme la fenêtre. Pas dans un fichier local que personne ne retrouve trois semaines plus tard.

Un harnais d'équipe conserve les résultats à un endroit connu. Consultable par ceux qui en ont besoin. Versionné pour qu'on puisse relire une review antérieure, comparer deux passes, comprendre ce qui a changé.

4. Qu'est-ce qui circule ?

Les règles de review, les vérificateurs, les profils d'agent, les cartes de domaine : ce sont des produits de l'équipe. Ils ont vocation à être partagés. Une carte de code coûte des heures d'agent à produire ; la refaire sur six machines, c'est payer six fois pour six réponses légèrement différentes.

Mais les sessions, les brouillons, les todos personnelles, les questions qu'on se pose à soi-même : ce sont des traces de travail. Elles n'ont pas vocation à circuler par défaut. Chacun décide de ce qui sort.

Un harnais d'équipe fait la distinction. Il partage ce qui doit être partagé, il garde ce qui doit rester privé. Et il demande, à chaque fois, avant de faire circuler quelque chose.

5. Qu'est-ce qui ne sort jamais ?

Les jetons d'API, les chemins absolus, les secrets, les identifiants de session. Chaque poste garde son accès. Le travail circule, pas les identifiants.

Cette règle doit être vérifiée automatiquement, pas laissée à la discipline de chacun. Un secret commité dans un dépôt partagé est un secret perdu. Il faut que l'outil refuse, à la source, ce qui ne doit pas sortir.