Structurer un harness de développement assisté par IA : maintenabilité, sécurité et portabilité entre assistants

On discute beaucoup du modèle à choisir et de la façon de rédiger un bon prompt. Sur le terrain, ce n'est pas là que se joue la différence. Deux équipes qui utilisent le même modèle obtiennent des résultats très différents selon l'état du projet qu'elles lui confient : documentation d'architecture à jour ou absente, tests fiables ou inexistants, commandes de build reproductibles ou connues d'une seule personne, secrets protégés ou traînant dans un fichier .env lisible par tous les outils.

Cet article propose une méthode pour construire cet environnement : un harness de développement. Il s'adresse aux développeurs expérimentés, aux Tech Leads, aux CTO et aux responsables d'ingénierie qui veulent que le développement assisté par IA reste maintenable, collaboratif, sûr et indépendant d'un fournisseur.

Une précision sur la nature des informations. Je distingue trois niveaux, signalés dans le texte :

• Documenté : une fonctionnalité décrite dans la documentation officielle de l'outil, consultée en octobre 2026. Ces points évoluent vite : vérifiez la version que vous utilisez.
• Pratique : une bonne pratique d'ingénierie générale, indépendante d'un outil.
• Avis : une recommandation personnelle, issue de l'expérience, donc discutable.

1. Comprendre le harness de développement

Une définition de travail

Dans le contexte des agents de développement, j'appelle harness l'ensemble de ce qui entoure le modèle de langage pour le rendre utile, contrôlable et reproductible : les instructions, les outils, les permissions, les tests, les procédures et les mécanismes de vérification. Le terme n'a pas de définition normative : c'est une métaphore (le harnais qui équipe et guide), et d'autres auteurs en proposent des variantes. Avis : cette définition large est utile parce qu'elle oblige à regarder au-delà du prompt.

Quatre couches à ne pas confondre

Quand un résultat est décevant, la tentation est de blâmer le modèle. Plus souvent, le défaut est dans les trois autres couches : un contexte contradictoire, un outil trop permissif, un projet qu'aucune commande unique ne permet de tester.

Pourquoi un bon modèle ne compense pas un projet mal structuré

Un modèle puissant raisonne mieux, mais il ne peut pas deviner ce qui n'est écrit nulle part : la raison d'une convention, la dépendance interne à ne pas toucher, le test qui est instable depuis six mois. Dans un projet sans tests, l'agent n'a aucun moyen de vérifier son propre travail : il propose du code plausible, et la vérification retombe sur la relecture humaine, qui devient le goulot d'étranglement. À l'inverse, un projet où scripts/test.sh s'exécute en deux minutes et échoue clairement donne à l'agent une boucle de retour qu'il peut exploiter seul.

Pratique : les mêmes éléments (règles écrites, tests, outils, garde-fous) améliorent le travail des humains et celui des agents. Investir dans le harness n'est donc pas un coût réservé à l'IA, c'est une dette d'ingénierie que l'IA rend simplement plus visible et plus coûteuse.

2. Organiser le contexte du projet

Le principe : une source de vérité, plusieurs lecteurs

Le contexte d'un projet est ce qu'un nouvel arrivant, humain ou agent, doit savoir pour travailler sans faire de dégâts. Le risque classique est que chaque développeur, et chaque agent, reconstruise sa propre compréhension, avec des divergences qui apparaissent à la revue de code. La parade est de rendre le contexte explicite, versionné et unique.

Les éléments utiles, par ordre approximatif de rentabilité :

• Un README court : à quoi sert le projet, comment l'installer, comment lancer les tests.
• La documentation d'architecture : les composants, leurs responsabilités, les flux de données, les contraintes. Un schéma et deux pages valent mieux que trente pages obsolètes.
• Les décisions d'architecture documentées (ADR) : un court document par décision (contexte, options, choix, conséquences). C'est ce qui évite de rediscuter indéfiniment, et d'obtenir d'un agent qu'il « corrige » un choix délibéré.
• Les conventions de code : nommage, structure des modules, gestion des erreurs, journalisation. Idéalement vérifiées par un linter plutôt que seulement décrites.
• La structure des répertoires : où va quoi, avec les zones à ne pas modifier (code généré, dépendances copiées).
• Les procédures de build, de test et de déploiement : sous forme de scripts versionnés (scripts/), pas de paragraphes à recopier.
• La gestion des dépendances et des versions : fichiers de verrouillage, politique de mise à jour, versions d'exécution attendues.

Garder les instructions courtes, et pointer vers le reste

Documenté : les assistants chargent généralement leurs fichiers d'instructions dans le contexte du modèle, et certains plafonnent leur taille. La documentation de Codex indique par exemple une limite par défaut de 32 KiB pour l'ensemble des fichiers d'instructions combinés. Pratique : même sans plafond, un fichier d'instructions volumineux dilue l'attention du modèle et consomme du contexte à chaque requête.

Deux défauts reviennent souvent :

1. Le fichier d'instructions devenu fourre-tout : à l'origine quelques règles, puis un journal de décisions, un état d'avancement, des notes de migration. Ce qui est vrai à un instant donné (l'état d'une migration, par exemple) n'a pas sa place dans un contexte permanent : il vieillit, et le modèle le lit comme une vérité.
2. Les sources de vérité multiples : la même information recopiée à plusieurs endroits, qui divergent avec le temps. Quand deux documents se contredisent, l'agent choisit l'un des deux, sans que personne ne le sache.

Avis : appliquez une règle simple. Le fichier d'instructions contient ce qui est toujours vrai et toujours utile : les commandes, les règles de travail, les interdits, et des liens vers la documentation détaillée que l'agent ira lire à la demande. Tout le reste vit dans docs/, avec un seul propriétaire par sujet.

Attention à la documentation générée par l'IA

Faire écrire la documentation par un assistant est tentant, et souvent utile comme première version. Le danger est la boucle : un agent relit une documentation qu'un agent a produite sans vérification, et la traite comme un fait établi. Pratique : marquez le statut de ce qui est généré (« non revérifié »), faites relire par un humain ce qui sert de référence, et préférez les documents courts, vérifiables, rattachés à un propriétaire.

3. Maintenabilité et travail collaboratif

Des conventions communes pour les humains et les agents

L'objectif est qu'une modification ressemble au reste du code, qu'elle ait été écrite par une personne ou par un agent. Cela passe par des conventions explicites et surtout vérifiables automatiquement : formateur, linter, vérification de types, tests. Une règle écrite que rien ne contrôle est une suggestion. Une règle appliquée par la CI est un fait.

Encadrer les modifications automatiques

Les agents ont tendance à en faire trop : reformater un fichier entier, renommer au passage, « améliorer » du code voisin. Cela produit des diffs difficiles à relire et des conflits. Quelques pratiques qui limitent ces dérives :

• Définir le périmètre dans la demande : les fichiers ou modules concernés, ce qui est hors périmètre, ce qui ne doit pas changer.
• Demander un plan avant le code pour les tâches non triviales, et le valider.
• Exiger des changements petits et indépendants : un sujet par branche, un sujet par revue.
• Tolérer zéro changement cosmétique hors périmètre, ou les isoler dans un commit dédié.
• Rendre le diff lisible : si un changement dépasse ce qu'un humain peut relire sérieusement, c'est un signal pour le découper.

Un point de contrôle unique, versionné, que la CI et les agents appellent de la même manière, évite les divergences entre « ce que fait l'agent en local » et « ce que vérifie la CI » :

#!/usr/bin/env sh
# scripts/check.sh : le même contrôle pour les humains, les agents et la CI
set -eu
scripts/lint.sh          # formatage, règles de style, types
scripts/test.sh          # tests unitaires et d'intégration
scripts/scan-secrets.sh  # détection de secrets (outil au choix)

Git, revues et tests comme filet de sécurité

Pratique : travailler sur une branche dédiée, jamais directement sur la branche principale ; passer par une revue de code, humaine pour tout ce qui compte ; faire exécuter les tests et les contrôles par la CI, hors de portée de l'agent. Ce dernier point est essentiel : la CI est le seul garde-fou que l'agent ne peut pas contourner en modifiant ses propres règles.

Pour éviter les conflits entre modifications humaines et générées, les mêmes règles qu'en équipe s'appliquent : branches courtes, rebase ou fusion fréquents, propriété claire des zones du code, pas de longue session d'agent isolée sur des fichiers que d'autres modifient.

Assurer la continuité quand quelqu'un d'autre reprend

Un agent n'a pas de mémoire fiable d'une session à l'autre, et un développeur peut reprendre le travail d'un autre. Dans les deux cas, ce qui permet la reprise est écrit : la description de la tâche, l'état d'avancement, les décisions prises, ce qui reste à faire. Pratique : un court fichier de suivi par tâche longue (dans la demande de fusion ou dans le ticket, plutôt que dans une conversation), avec les commandes pour reproduire l'état actuel. Une conversation n'est pas une documentation : les décisions durables doivent atterrir dans le dépôt ou dans l'outil de ticketing.

4. Sécurité et protection des données sensibles

La commodité d'un agent vient de ce qu'il lit des fichiers, exécute des commandes et parle à des services. C'est exactement ce qui le rend dangereux s'il est mal encadré. Cette section est volontairement la plus stricte.

Les secrets

• Ne jamais placer de secret dans un prompt, un fichier d'instructions ou un dépôt. Cela inclut les mots de passe, les jetons, les clés d'API, les certificats et le contenu des fichiers .env. Ce qui est envoyé à un modèle externe sort de votre périmètre ; ce qui est commité reste dans l'historique.
• Gérer les secrets hors du dépôt : gestionnaire de secrets, variables injectées par la CI ou l'environnement d'exécution, fichiers .env.example sans valeurs réelles dans le dépôt.
• Ne laisser sur le poste de travail que ce dont la tâche a besoin. Un poste de développement qui contient les fichiers d'environnement de production donne à tout outil lancé sur ce poste un accès à la production.
• Ajouter un contrôle de détection de secrets dans la CI et, si possible, avant le commit.

Documenté : Claude Code permet de refuser la lecture de chemins précis par des règles de refus dans ses fichiers de configuration (par exemple Read(./.env)). La documentation précise qu'un fichier de type .claudeignore n'a pas d'effet et que ces règles de refus ne remplacent pas une isolation au niveau du système d'exploitation, car elles ne couvrent pas tous les moyens d'accéder à un fichier (un programme lancé par le shell, par exemple). Pratique : traitez les règles de l'outil comme une première couche, pas comme une garantie.

Voici à quoi ressemble ce type de règle dans le fichier de configuration d'un projet. C'est un exemple à adapter : vérifiez la syntaxe exacte dans la documentation de la version que vous utilisez.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Les permissions minimales

Pratique : appliquez le principe du moindre privilège aux agents comme à n'importe quel compte de service.

• Donnez l'accès en lecture aux seuls répertoires nécessaires, en écriture à un périmètre étroit.
• Listez les commandes autorisées plutôt que d'interdire une à une les commandes dangereuses.
• Contrôlez l'accès réseau : un agent qui peut appeler n'importe quelle URL peut aussi y envoyer du code ou des données.
• Séparez les environnements : l'agent travaille sur un environnement de développement, jamais avec des identifiants de production.
• Retirez de la portée de l'agent les actions irréversibles ou coûteuses : déploiement en production, suppression de données, envoi de messages à des clients, paiements.

Documenté : Claude Code évalue les règles de refus et de demande de confirmation quelle que soit la réponse d'un hook, et un hook peut durcir les règles mais pas lever un refus. Les hooks (par exemple avant l'exécution d'un outil) permettent d'ajouter des contrôles programmés. D'autres outils disposent de mécanismes comparables, de forme différente : lisez leur documentation plutôt que d'en supposer l'équivalence.

Validation humaine des opérations sensibles

Avis : définissez par écrit la liste des opérations qui exigent une validation humaine explicite, et faites-la respecter par un mécanisme technique (demande de confirmation, permission refusée par défaut), pas seulement par une phrase dans un fichier d'instructions. Un exemple typique et fréquent : une commande de déploiement en production qui existe dans le projet et que l'agent peut lancer sans confirmation parce que personne n'a pensé à l'interdire.

MCP, extensions et outils tiers

Les serveurs MCP et les extensions donnent à l'agent de nouvelles capacités : accès à des bases de données, à des API, à des navigateurs. Chacun élargit la surface d'attaque.

• Traitez un serveur MCP comme du code que vous exécutez, avec les droits de l'utilisateur : vérifiez la provenance, les permissions demandées, la maintenance.
• Versionnez la liste des serveurs autorisés pour le projet, et évitez les extensions personnelles imposées implicitement aux collègues.
• Gardez à l'esprit l'injection de prompt : un agent qui lit une page web, un ticket ou un fichier tiers peut y rencontrer des instructions hostiles. Moins il a de pouvoirs, moins ces instructions sont dangereuses.

Garanties de l'infrastructure et garanties déclaratives

C'est la distinction la plus importante de cette section. Une garantie d'infrastructure est imposée par un système que le modèle ne contrôle pas : un compte sans droit d'écriture sur la production, un réseau qui bloque les sorties, un conteneur sans accès aux secrets, une CI qui refuse la fusion. Une garantie déclarative est une phrase demandant au modèle de se comporter : « ne jamais lire les fichiers .env », « ne pas déployer sans accord ». La seconde est utile pour orienter le comportement, mais elle n'empêche rien : un modèle peut l'ignorer, mal l'interpréter, ou la perdre lorsque le contexte est tronqué. Pour toute règle dont la violation coûterait cher, cherchez la version d'infrastructure.

Code confidentiel et outils externes

Lorsqu'un modèle ou un outil externe traite du code confidentiel, la question est d'abord contractuelle et organisationnelle : où sont envoyées les données, combien de temps sont-elles conservées, sont-elles utilisées pour l'entraînement, quel est le niveau de service (offre entreprise ou grand public) ? Pratique : classez le code et les données par sensibilité, définissez ce qui peut sortir de l'organisation, utilisez des offres dont les conditions sont documentées et validées par votre sécurité, et conservez la possibilité d'un déploiement local ou privé pour les contenus les plus sensibles. Pour des données soumises à la réglementation, faites valider l'usage par les responsables de la conformité avant le déploiement, pas après.

5. Compatibilité entre les LLM et les assistants

Le risque : un projet prisonnier d'un seul outil

Chaque assistant a ses conventions : un fichier d'instructions, un répertoire de configuration, un format de commandes et de règles. Un projet dont toute la connaissance est enfermée dans le format d'un seul outil devient dépendant de lui : changer d'assistant, ou faire cohabiter plusieurs outils dans une même équipe, oblige à tout réécrire. La parade est d'organiser le projet autour d'une base documentaire indépendante du fournisseur, avec de petites couches d'adaptation par outil.

Ce que disent les conventions des principaux outils (octobre 2026)

Le tableau ci-dessous résume ce que j'ai pu vérifier dans la documentation officielle ou, à défaut, ce qui reste à confirmer. Les noms de fichiers et leur prise en charge évoluent régulièrement.

Le format AGENTS.md est présenté par ses promoteurs comme un format ouvert, destiné à plusieurs assistants. Plusieurs sources secondaires citent d'autres outils qui l'utilisent (Cursor, Aider, Zed, Jules, Devin), mais je n'ai pas vérifié chacune de ces affirmations dans la documentation de l'outil concerné : ne présentez pas AGENTS.md comme universel dans votre documentation interne avant d'avoir testé chaque outil que vous utilisez. Un fichier n'est pas un standard parce qu'il est répandu.

Une architecture en couches

Voici l'architecture que je recommande, présentée comme une illustration à adapter (Avis) :

1. Documentation commune du projet, indépendante de tout outil : README.md, docs/architecture/, docs/decisions/. C'est la source de vérité, lue par les humains comme par les agents.
2. Instructions générales pour les agents : un fichier court (AGENTS.md) qui contient les commandes, les règles de travail, les interdits, et des liens vers la documentation.
3. Couches d'adaptation par outil : de petits fichiers qui pointent vers les instructions communes (par exemple un CLAUDE.md qui importe AGENTS.md) et qui ne contiennent que ce qui est propre à l'outil.
4. Règles et configuration spécifiques à chaque outil : permissions, hooks, serveurs MCP autorisés, commandes personnalisées, dans le répertoire de l'outil (.claude/, .codex/, .gemini/, etc.).
5. Contrôles de sécurité : détection de secrets, analyse des dépendances, permissions minimales, validation humaine des opérations sensibles.
6. Tests automatisés et CI : la boucle de vérification commune à tous les outils, la seule qui ne dépend pas du modèle.
7. Procédures de validation : revue de code, critères de fin de tâche, journal des décisions.

Les couches 1, 2, 5, 6 et 7 sont portables par construction. Les couches 3 et 4 sont celles où l'on accepte la dépendance, mais en la gardant petite, documentée et remplaçable.

Les limites de la portabilité

Rendre un projet compatible avec plusieurs assistants ne garantit pas des résultats identiques. Chaque modèle interprète différemment les mêmes instructions, suit plus ou moins fidèlement les règles longues, gère différemment le contexte et les outils. Deux assistants qui lisent le même AGENTS.md peuvent produire des travaux différents. Pratique : la portabilité garantit que le projet reste compréhensible et exploitable ; seule une évaluation sur vos propres tâches renseigne sur la qualité obtenue avec chaque outil (voir la section suivante).

Il faut aussi accepter qu'une partie des fonctionnalités n'ait pas d'équivalent entre outils (hooks, sous-agents, commandes personnalisées, formats de permissions). Mieux vaut le documenter que de simuler une équivalence qui n'existe pas.

6. Rétrocompatibilité et pérennité

Un harness est un produit interne : il évolue, et ses évolutions peuvent casser les usages existants. Quelques pratiques pour le faire évoluer sans surprise :

• Versionner les instructions et les configurations dans le dépôt, avec revue de code et historique, comme du code. Un changement de règle est un changement du système.
• Documenter les dépendances aux fonctionnalités propres à un fournisseur : quel hook, quelle commande, quelle version minimale de l'outil. Une liste courte dans docs/ suffit.
• Maintenir des tâches de référence : un petit ensemble de tâches représentatives (corriger un bogue, ajouter un endpoint, refactorer un module, écrire un test) avec le résultat attendu et la manière de le vérifier.
• Tester les mises à jour de modèle et d'outil sur ces tâches avant de les généraliser à l'équipe. Un changement de version peut modifier le comportement sans prévenir.
• Vérifier sur un échantillon représentatif, pas sur un seul exemple favorable : la variabilité entre exécutions est réelle.
• Conserver des procédures de repli : savoir revenir à une version précédente de l'outil ou du harness, et travailler sans assistant si nécessaire. Un harness dont l'absence bloque l'équipe est un risque.
• Éviter les dépendances implicites : ne comptez pas sur un format ou une capacité propriétaire non documentée, ni sur des plugins personnels installés sur un seul poste. Ce qui n'est pas dans le dépôt n'existe pas pour le reste de l'équipe.

7. Un exemple concret

Une structure de projet illustrative

La structure suivante est un exemple à discuter, pas une norme. Les commentaires indiquent ce qui relève d'une convention documentée de l'outil et ce qui reste à vérifier dans la version que vous utilisez.

project/
├── README.md                  # présentation, installation, lancement des tests
├── AGENTS.md                  # instructions générales, courtes, partagées
├── CLAUDE.md                  # adaptateur : importe @AGENTS.md (convention Claude Code)
├── GEMINI.md                  # adaptateur optionnel : import @AGENTS.md, à vérifier selon la version
├── docs/
│   ├── architecture/          # vue d'ensemble, composants, flux
│   └── decisions/             # ADR : une décision par fichier
├── tests/                     # tests automatisés
├── scripts/                   # setup.sh, test.sh, lint.sh : commandes uniques et versionnées
├── .claude/                   # settings.json : permissions, hooks (propre à Claude Code)
├── .codex/                    # configuration de projet de Codex, à vérifier selon la version
└── .gemini/                   # settings.json de Gemini CLI, à vérifier selon la version

Ne créez pas un répertoire de configuration « au cas où » : un fichier qu'aucun outil ne lit donne une fausse impression de sécurité. N'ajoutez une couche d'adaptation que lorsque l'outil correspondant est réellement utilisé dans l'équipe, et testez qu'il la prend bien en compte (par exemple en demandant à l'agent de citer les règles qu'il a chargées).

Un squelette d'AGENTS.md

Voici un point de départ volontairement court. L'idée est de renvoyer vers les scripts et la documentation plutôt que de tout répéter.

# Instructions pour les agents

## Contexte
Application X. Architecture : voir docs/architecture/overview.md.
Décisions structurantes : voir docs/decisions/.

## Commandes
- Installer : scripts/setup.sh
- Tests : scripts/test.sh (à lancer avant toute demande de fusion)
- Lint et types : scripts/lint.sh

## Règles de travail
- Une tâche, une branche. Pas de modification hors du périmètre demandé.
- Proposer un plan avant de modifier plus de trois fichiers.
- Ne pas reformater les fichiers non concernés.
- Toute décision d'architecture notable donne lieu à un ADR dans docs/decisions/.

## Interdits
- Ne jamais lire, afficher ni écrire de secrets (fichiers .env, clés, jetons).
- Ne jamais lancer de déploiement, de migration de données ou de suppression sans validation humaine.

Ce fichier exprime des règles déclaratives. Pour celles qui comptent (secrets, déploiement), doublez-les par un mécanisme technique : permissions de l'outil, compte sans droit, CI bloquante.

Un cycle de travail en huit étapes

1. Comprendre le contexte. L'agent (ou le développeur) lit le README, l'architecture et les décisions pertinentes, et résume sa compréhension. Une erreur de compréhension se corrige à ce stade, pas dans le diff.
2. Définir le périmètre. Ce qui est demandé, ce qui est hors périmètre, les critères d'acceptation.
3. Élaborer un plan. Les fichiers concernés, les étapes, les risques, les tests à ajouter. Le plan est validé avant d'écrire du code.
4. Modifier le code. Par petites étapes, sur une branche dédiée, en lançant les tests au fur et à mesure.
5. Exécuter les contrôles. Tests, lint, types, détection de secrets, via les scripts du projet. Un échec se lit, il ne se contourne pas.
6. Examiner le diff. Relecture attentive de tout ce qui a changé, y compris ce qui n'était pas demandé. Les changements hors périmètre sont retirés.
7. Faire valider. Revue de code par un humain, avec une explication de ce qui a été fait et de ce qui n'a pas été vérifié.
8. Documenter les décisions utiles. Un ADR si un choix structurant a été fait, une mise à jour de la documentation si un comportement a changé, une note de reprise si le travail continue.

8. Checklist de maturité du harness

Cochez ce qui est vrai aujourd'hui dans votre projet, pas ce qui est prévu. Chaque section a le même poids : une faiblesse sur la sécurité ne se compense pas par de bons tests.

Contexte et documentation

• Un README permet d'installer et de tester le projet sans aide extérieure.
• L'architecture est documentée et datée, avec un propriétaire identifié.
• Les décisions structurantes sont consignées (ADR).
• Le fichier d'instructions des agents est court et pointe vers la documentation, sans journal ni état d'avancement.
• Chaque information importante n'existe qu'à un seul endroit.
• La documentation générée par IA est identifiée et relue par un humain avant d'être considérée comme fiable.

Qualité et collaboration

• Une commande unique lance les tests, une autre le lint et les types.
• La CI exécute ces contrôles et bloque la fusion en cas d'échec.
• Les agents travaillent sur des branches dédiées, jamais sur la branche principale.
• Toute modification passe par une revue de code humaine.
• Les changements hors périmètre sont repérés et retirés à la revue.
• Une tâche longue laisse une note de reprise en dehors de la conversation.

Sécurité

• Aucun secret dans les dépôts, les prompts ni les fichiers d'instructions, avec une détection automatique.
• Les agents n'ont accès ni aux secrets de production ni aux fichiers d'environnement correspondants.
• Les permissions des agents sont minimales et versionnées.
• Les opérations irréversibles (déploiement, suppression, envoi) exigent une validation humaine imposée techniquement.
• La liste des serveurs MCP et extensions autorisés est connue et revue.
• Les règles critiques reposent sur une garantie d'infrastructure, pas seulement sur une consigne.
• Les conditions de traitement des données par les outils externes sont validées pour le code confidentiel.

Portabilité et pérennité

• La documentation du projet ne dépend d'aucun format propriétaire.
• Les adaptations propres à chaque outil sont petites, documentées et listées.
• Les instructions et configurations sont versionnées avec le code.
• Un jeu de tâches de référence permet de comparer des versions de modèle ou d'outil.
• Une mise à jour d'outil est testée avant d'être généralisée.
• Une procédure de repli existe, y compris pour travailler sans assistant.

Lecture du résultat

À titre indicatif (Avis, cette grille n'a rien de normatif) : en dessous de la moitié des cases cochées, le harness repose surtout sur la bonne volonté des personnes. Entre la moitié et les trois quarts, il est utilisable mais fragile sur certains points : commencez par la section Sécurité. Au-delà, l'enjeu devient l'entretien : mettre à jour, mesurer, simplifier.

Conclusion

Le choix du modèle compte, mais il change tous les quelques mois. Ce qui dure, c'est le système de travail construit autour de lui : un contexte clair et unique, des règles que des outils font respecter, des tests qui permettent de vérifier, des garde-fous qui reposent sur l'infrastructure plutôt que sur la confiance, et une organisation qui n'est pas prisonnière d'un fournisseur. Un bon harness profite aux humains comme aux agents, et il garde sa valeur le jour où l'on change d'assistant.

Références et statut des informations

Les documentations officielles ci-dessous ont été consultées en octobre 2026. Leur contenu évolue : vérifiez la version de l'outil que vous utilisez.

• Claude Code, mémoire et fichiers d'instructions : https://code.claude.com/docs/en/memory
• Claude Code, permissions : https://code.claude.com/docs/en/permissions
• OpenAI Codex, instructions avec AGENTS.md : https://developers.openai.com/codex/guides/agents-md
• Gemini CLI, fichiers GEMINI.md : https://geminicli.com/docs/cli/gemini-md
• Cline, personnalisation : https://docs.cline.bot/customization

Les informations sur Roo Code, sur la liste des outils compatibles avec AGENTS.md et sur la priorité des configurations de Codex proviennent en partie de sources secondaires et sont signalées comme telles dans le texte. Les recommandations marquées Avis sont personnelles.