FORM-IA-DEV · 1 jour · Spécialisation
Agents codeurs : industrialiser l’assistance au développement
Vos équipes utilisent déjà un agent codeur. La question n’est plus s’il faut y aller, mais comment l’intégrer sans dégrader la base de code, la revue et la sécurité.
Objectif pédagogique
Cadrer ce qu’un agent a le droit de modifier, et ce qui reste humain
Écrire des instructions de dépôt réellement suivies
Relire du code généré avec une grille adaptée à ses défauts propres
Poser des garde-fous CI qu’on a vus échouer au moins une fois
Mesurer l’apport sur la livraison, pas sur l’usage de l’outil
Pour qui ?
- Équipes de développement qui adoptent un agent codeur — ou l’ont adopté sans cadre
- Tech leads et architectes responsables de la qualité du dépôt
- Responsables CI/CD et sécurité applicative
- Managers cherchant à mesurer l’apport autrement qu’au ressenti
Prérequis
- Pratique courante de Git et d’une chaîne d’intégration continue
- Savoir lire une revue de code et un rapport de tests
- Aucun prérequis sur les agents IA
Programme — matin (théorie ~3h20)
| Module | Contenu | Durée |
|---|---|---|
| D1 | Panorama : complétion, agent de dépôt, agent de tâche — ce que chaque forme sait et ne sait pas faire | 40 min |
| D2 | Cadrer le périmètre : quels dépôts, quels fichiers, quelles branches. Le refus comme fonctionnalité | 40 min |
| D3 | Instructions de dépôt : règles vérifiables, pièges du projet, et pourquoi elles valent mieux qu’un bon prompt | 45 min |
| D4 | Revue du code généré : plausible mais faux, dépendance inventée, test qui teste l’implémentation | 45 min |
| D5 | Mesure et sécurité : indicateurs qui tiennent, secrets, licences, ce qui sort de l’entreprise | 40 min |
Programme — après-midi (labs ~3h30)
| Module | Contenu | Durée |
|---|---|---|
| TP1 | Fichier d’instructions de dépôt : diff figé avant / après sur la même demande, linter de règles vérifiables, gabarit et contre-exemple | 70 min |
| TP2 | Revue dirigée : six diffs générés, quatre défauts caractéristiques à trouver et nommer | 70 min |
| TP3 | Garde-fous CI : pas de fusion sans tests, détection de secrets, contrôle des dépendances, périmètre annoncé — chacun poussé à l’échec | 70 min |
| TP4 | Mesurer : soixante PR fictives, corrélations des indicateurs d’usage et de livraison avec les défauts en production | 40 min |
Les défauts que la revue habituelle laisse passer
- Dépendance inventée : le nom est plausible, l’erreur n’apparaît qu’à l’exécution
- Test qui rejoue la logique du code : vert, bien écrit, et ne détecte aucune régression
- Faux plausible : constante, format de date ou code d’erreur crédible mais inventé
- Périmètre débordé : le diff corrige aussi ce qu’on n’avait pas demandé
- Secret en dur déguisé en valeur d’exemple
Parti pris du lab
Les diffs de la revue dirigée sont figés dans le dépôt plutôt que générés en séance : l’exercice doit donner le même résultat d’une session à l’autre, ce qu’une génération en direct ne garantit pas.
Ce que le module ne couvre pas
- Le choix d’un outil du marché — le module est volontairement agnostique
- L’hébergement d’un modèle de code en interne
- La négociation contractuelle avec un fournisseur
Livrables participants
- Un fichier d’instructions de dépôt, écrit pour le projet du participant
- La grille de revue du code généré, en une page
- Trois garde-fous CI prêts à copier, chacun vu échouer en séance
- Le tableau des indicateurs à suivre — et de ceux à ne surtout pas suivre