Comment donner à un agent de code IA un savoir métier fiable

Un agent de code généraliste peut produire une réponse plausible tout en manquant le détail essentiel de votre stack : une API modifiée récemment, une limite de dépôt à ne pas franchir ou une convention qui protège la production. La solution n’est pas toujours un prompt plus long. Il vaut mieux fournir des indications métier courtes et réutilisables, ainsi qu’une définition de fini vérifiable.

1. Séparer les règles du projet et les procédures métier

Commencez par deux niveaux. Le premier est un contrat de dépôt concis : nature et structure du projet, commandes de build et de test, fichiers interdits et définition de “terminé”. La documentation JetBrains sur le comportement des agents décrit des fichiers comme AGENTS.md et CLAUDE.md comme des instructions qui voyagent avec le dépôt et peuvent être partagées entre outils.

Gardez cette couche stable et opérationnelle. Elle doit répondre à chaque tâche : où se trouve la logique métier, comment lancer les vérifications et que ne faut-il pas modifier ? Une règle propre à un seul flux mérite un skill séparé.

Le second niveau est le savoir métier : une recette ciblée pour une tâche récurrente, comme une migration de navigation Android, une modification de schéma ou une checklist de release. Un skill a besoin d’un déclencheur clair, de quelques actions et d’une validation explicite. Le contexte par défaut reste ainsi réduit.

2. Écrire un skill autour d’un manque de connaissance

Un bon skill existe parce que le modèle répète une erreur ou redécouvre sans cesse la même chose. La philosophie des Android Skills propose un test utile : les skills officiels répondent à des lacunes vérifiables, notamment quand les API évoluent ou qu’une équipe utilise une architecture personnalisée. Elle recommande aussi des sources fiables plutôt que de grandes collections non testées pouvant contenir des instructions malveillantes.

Un exemple minimal :

---
name: navigation-upgrade
description: Use when changing the app's Navigation 3 setup or upgrading its related APIs.
---

Before editing:
1. Inspect the current dependency versions and existing navigation tests.
2. Read the project's navigation conventions.
3. Confirm the target API in the approved platform documentation.

While editing:
- Make the smallest vertical change that satisfies the requested behavior.
- Do not replace the navigation architecture without approval.
- Preserve existing deep-link and back-stack behavior unless the task says otherwise.

Done means:
- The focused tests pass.
- The relevant build or lint command passes.
- The response names changed files, checks run, and unresolved risks.

L’exemple reste volontairement étroit. Il n’insère pas un manuel complet dans chaque prompt ; il définit quand la procédure s’applique, quoi inspecter, quelles limites respecter et comment prouver la fin du travail. Remplacez les vérifications par les commandes et conventions réelles de votre dépôt.

3. Faire inspecter l’agent avant l’action

Les agents de code combinent une demande avec le contexte de l’environnement, raisonnent dessus et exécutent des modifications, tests et builds. C’est le flux décrit dans les recommandations AWS pour les agents de code. Vos instructions doivent rendre ces étapes visibles.

Une demande pratique comporte quatre parties :

1. Contexte : fonctionnalité, répertoires concernés et contraintes.
2. Plan : fichiers et vérifications prévus avant l’édition.
3. Changement : implémentation minimale répondant aux critères d’acceptation.
4. Preuve : tests, lint, build ou contrôles manuels exacts.

Cela évite de coder depuis une seule phrase, de découvrir l’architecture trop tard et de compenser par une réécriture large. L’inspection est la façon dont l’agent obtient le contexte dont dépendent ses décisions.

4. Donner une boucle de feedback courte

Les indications métier expliquent le projet, mais les contrôles exécutables montrent si le changement fonctionne. Le guide TDD actuel de VS Code sépare une phase red avec test en échec, une phase green avec implémentation minimale et une phase refactor qui améliore la structure tout en gardant les tests verts.

Trois agents sophistiqués ne sont pas nécessaires. Pour une petite tâche, demandez d’abord un test en échec ou de caractérisation, puis implémentez. Finissez par un test ciblé et les garde-fous habituels. Un échec est une information sur le besoin ou l’environnement, pas une raison de le dissimuler dans un résumé trop assuré.

5. Réviser puis retirer les instructions

Traitez un skill comme une infrastructure d’ingénierie versionnée. Révisez-le quand le framework change, quand l’agent répète une erreur ou quand un contrôle devient bruyant. Le guide Android Skills présente les skills comme susceptibles d’être dépréciés : les modèles progressent, certaines consignes deviennent inutiles et les nouvelles API créent de nouveaux manques.

Une boucle de maintenance légère :

• Conserver une tâche exemple qui exerce le skill.
• Noter les fichiers attendus et les commandes de validation.
• Relancer après une modification du skill ou du modèle.
• Retirer les instructions devenues inutiles.
• Garder les actions sensibles à la sécurité optionnelles et révisables.

Le but n’est pas de faire paraître l’agent plus expert, mais de rendre le comportement correct reproductible : contrat de dépôt court, procédure métier ciblée et définition de fini exécutable.