Lock-in des agents : capitalise hors outil

Un agent de code devient plus facile à remplacer quand les règles du projet et la preuve du travail restent dans ton dépôt. Changer de fournisseur sans sortir ces actifs du produit laisse une bonne partie du lock-in en place.

Dans mon retour de migration, publié en février puis actualisé en juillet 2026, j’ai raconté le départ de Claude Code pour OpenCode, puis Kilo Code CLI. Dans Anthropic, le Apple de l’IA, publié en juillet, j’ai documenté le retour pour l’écosystème intégré. Ce parcours explique le compromis ; il ne prouve pas que mes hooks se transportent tels quels.

La parade proposée ici consiste à séparer ce qui décrit le travail de ce qui branche un outil dessus. Tu peux choisir une intégration confortable et garder les critères qui permettront d’en sortir. Aucune comparaison contrôlée de cette méthode n’est présentée ici.

Ce qui mérite de vivre hors produit

Les conventions du projet, les décisions d’architecture et les critères d’acceptation ont une valeur indépendante du modèle. Une tâche devrait préciser le comportement attendu, les limites de modification et la preuve nécessaire pour être acceptée. Ces éléments restent utiles au prochain agent, et au développeur qui reprendra sans agent.

Le format ouvert AGENTS.md fournit un emplacement pour les commandes et les instructions du projet. Sa documentation décrit un fichier Markdown sans champs obligatoires, pris en charge par plusieurs agents. Cela facilite le partage du texte. La façon de le charger et les éventuels conflits d’instructions restent à vérifier dans l’outil choisi.

La règle vaut aussi pour le routage des modèles : conserver le critère de choix, par exemple réserver le raisonnement complexe aux tâches qui le demandent, permet de changer les références de modèles ensuite. Une configuration remplie de noms de fournisseurs conserve moins bien cette intention qu’une décision explicitée à côté.

Le guide des règles d’équipe détaille ce socle. Pour une petite tâche, le ticket et les tests existants peuvent suffire. Accumuler des fichiers de contexte que personne ne relit ajouterait une autre dette.

Un gate portable a un adaptateur

Une règle comme « refuser une livraison sans validation » peut survivre au changement d’agent. Le mécanisme qui intercepte l’action dépend du harnais. La documentation des hooks Claude Code décrit des événements, des entrées JSON et des décisions propres à son cycle d’exécution. PreToolUse intervient avant l’appel d’outil et peut le bloquer ; PostToolUse intervient après sa réussite.

Copier le script sans vérifier le moment où il tourne peut donc changer la protection. Un contrôle après l’action ne remplace pas un refus avant l’action. Le portage doit établir quel événement reçoit quoi, et comment le refus est effectivement appliqué.

L’actif durable comprend la règle, le contrôle quand il peut être isolé, et ses cas de test. L’adaptateur traduit l’événement du harnais vers ce contrôle. Pour un gate de review, les cas devraient couvrir une validation absente, une validation périmée après modification et une validation valable. Il faut aussi vérifier qu’un cas autorisé passe : les faux positifs font partie du coût.

J’ai documenté un contournement de mon propre gate quand l’estampille et le commit étaient enchaînés dans le même appel shell. Ce défaut historique justifie un cas de régression dans un portage ; il ne démontre pas l’équivalence de deux harnais. Les protections placées dans la CI peuvent rester communes, sans garantir à elles seules le blocage local.

Faire une bascule dont le résultat se lit

La méthode proposée commence par une tâche représentative, sur le même état du dépôt dans deux espaces isolés. Fixe les critères avant de lancer les agents. Le guide du workflow agentique fournit la logique de décomposition en unités vérifiables.

Prépare ensuite un paquet de reprise : intention, fichiers concernés, décisions retenues, commandes de vérification et travail restant. Ce résumé appartient au projet. Il évite de faire dépendre toute la reprise d’un historique de conversation que l’autre produit ne sait pas importer.

Porte les adaptateurs nécessaires et vérifie leur comportement avant de leur confier une action sensible. Exécute la tâche avec les mêmes critères d’acceptation. Note séparément le temps de préparation, le portage des gates, l’exécution et les corrections en revue. Le coût d’apprentissage mérite sa propre ligne ; une première prise en main ne mesure pas un usage stabilisé.

Le résultat attendu de cet exercice est une décision lisible : quels actifs ont été réutilisés, quels contrôles ont dû être adaptés, quelles capacités manquent et si le livrable passe les mêmes critères. Un fichier copié ou une session qui démarre ne suffit pas à établir cette équivalence.

Une sortie de secours se maintient

Les connecteurs, les autorisations et les historiques de session ne suivent pas automatiquement les conventions Markdown. Si une reprise perd l’accès à une source utile, il faut compter le temps de reconstruction ou reconnaître la capacité absente. L’intégration peut rester le meilleur choix pour ton usage.

Une voie alternative inutilisée demande aussi des mises à jour, des accès valides et des exercices de reprise. Prévois une cadence proportionnée au risque et note l’effort réel. Une personnalisation individuelle abandonnée au passage ne constitue pas automatiquement une dépendance collective.

Tu peux commencer par une seule tâche et ses contrôles critiques. Si les critères survivent mais que le portage coûte trop cher, garde l’intégration en connaissance de cause. Le bénéfice reste là : le prochain changement d’outil aura un contrat de travail et une preuve à respecter.