Plan de la formation
Ingénierie agentique : la formation pratique · Module 6: L’ingénierie agentique en équipe
Conventions d’équipe et prompts partagés
Cinq devs qui promptent chacun à leur façon, ça donne cinq codebases. Faites monter ce qui marche : habitude perso, prompt partagé, fichier d’instructions, puis vérification automatique.
Leçon 21 / 24 · ⏱ 8 min
En équipe, le difficile avec les agents, ce n’est pas qu’une personne obtienne de bons résultats. C’est que cinq personnes obtiennent des résultats cohérents. Sans conventions communes, l’agent de chaque dev écrit du code dans un dialecte un peu différent.
La solution n’est pas un gros document de politique. C’est une habitude : quand quelque chose marche deux fois, on le rapproche d’un cran du repo.
L’échelle de promotion
Chaque barreau échange de la flexibilité contre de la fiabilité. Un prompt dans la bibliothèque dépend encore de quelqu’un qui pense à le choisir. Une ligne dans le fichier d’instructions est lue à chaque exécution. Une règle de linter, elle, ne s’oublie pas.
Ma règle : si une règle peut être vérifiée mécaniquement, elle va au barreau 5. Le fichier d’instructions sert aux jugements qu’un linter ne peut pas porter.
Où ça va?
Classez chaque convention sur le barreau où elle rapporte le plus. Deux ou trois se discutent; l’explication dit comment je trancherais.
🎮 Placez la convention
1 / 8 · Pointage: 0
Où cette règle devrait-elle vivre dans une équipe qui utilise des agents de code?
Les fichiers d’instructions eux-mêmes, ce qu’on y met et leur longueur, sont couverts au module 2. Ici, la question, c’est comment une équipe les garde vivants.
Prompts perso vs conventions partagées
✕ Chacun pour soi
- –Chaque dev garde ses prompts dans un fichier de notes privé
- –La même erreur est corrigée dans cinq conversations
- –Le style du code dépend de qui a lancé l’agent
- –Les nouveaux devinent les habitudes de l’équipe
- –Personne ne sait quel prompt est le bon
✓ Partagé et versionné
- +Les prompts vivent dans le repo, près du code qu’ils touchent
- +Une correction répétée devient une ligne du fichier d’instructions
- +Les changements de conventions passent par une pull request
- +Chaque prompt partagé a un responsable et un objectif d’une ligne
- +Les prompts périmés sont supprimés, pas collectionnés
Un prompt partagé qui vaut la peine
Un bon prompt partagé se lit comme un petit brief avec des trous à remplir. Les trous, c’est là que la personne qui l’utilise ajoute son jugement.
# prompts/ajouter-feature-flag.md
# Responsable : équipe plateforme. Objectif : ajouter un flag de bout en bout sans oublier d’étape.
Ajoute un feature flag nommé {NOM_DU_FLAG} qui contrôle {COMPORTEMENT}.
1. Enregistre-le dans la config des flags, désactivé par défaut.
2. Contrôle le comportement à {POINT_D_ENTREE} seulement. Pas de vérifs éparpillées.
3. Ajoute un test avec le flag activé et un avec le flag désactivé.
4. Liste chaque fichier modifié et tout ce que tu n’as pas pu vérifier.
Ne touche pas aux autres flags et ne refactorise pas le code autour.Avant de continuer
✅ À retenir
0 / 5 complété