L'IA au service du développeur : de l'assistance à l'intégration
- Durée
- Durée :2 jours
- Niveau
- Niveau :Fondamental
- Certification
- Certification :Non
1590€ HT
Prochaine session :
Formation Spec-Driven Development : piloter les agents IA par la spécification
Faire de la spécification le pilote du développement agentique, et le tenir à l'échelle d'une équipeDescription de la formation spec-driven development
Les agents de code ne sont plus limités par leur capacité à écrire du code : ils le sont par la qualité de ce qu'on leur donne à lire. Le Spec-Driven Development (SDD) répond à ce déplacement en faisant de la spécification l'artefact qui pilote le cycle de développement, rédigée, versionnée et revue dans le dépôt, au même titre que le code.
La formation part d'un constat honnête sur l'état de la pratique en 2026. La promesse fondatrice, selon laquelle la spécification remplacerait le code source, n'est plus réellement défendue : le marché a convergé vers une approche ancrée, où le code reste la source de vérité et la spécification l'artefact durable d'intention. Et avec un agent moderne, le Spec-Driven Development se pratique sans framework dédié. La question utile n'est donc pas quel outil adopter, mais comment obtenir de la discipline là où une consigne ne suffit pas.
Deux journées entièrement outillées : mise en œuvre de la boucle complète sous GitHub Spec Kit avec un agent de code, application à un dépôt existant, puis construction des garde-fous qui rendent la pratique tenable au-delà du développeur isolé, contraintes exécutables plutôt que recommandations, standard d'équipe, état durable sur projet long, revue du code généré, portabilité et maîtrise des coûts.
Programme de la formation
Objectif opérationnel :
Savoir conduire un développement piloté par la spécification avec un agent de code, et définir la convention d'équipe qui rend cette pratique reproductible sur un projet long.
Objectif pédagogiques :
À l'issue de cette formation Spec-Driven Development : piloter les agents IA par la spécification, vous aurez acquis les connaissances nécessaires pour :
- Distinguer les approches spec-anchored et spec-as-source et choisir celle qui convient à un contexte donné
- Mettre en œuvre la boucle du Spec-Driven Development : constitution, spécification, plan, tâches, implémentation
- Rédiger un fichier de contexte projet qu'un agent respecte effectivement
- Utiliser GitHub Spec Kit avec un agent de code sur un projet neuf
- Appliquer la démarche à une base de code existante
- Réviser du code généré et détecter la dérive entre spécification et implémentation
- Définir les garde-fous d'équipe : contraintes exécutables, standard partagé, état durable sur projet long
- Identifier les situations où le Spec-Driven Development ne se justifie pas
Jour 1 — La boucle du Spec-Driven Development
Les pratiques actuelles
Le déplacement du goulot d'étranglement : de la production de code à l'expression de l'intention
La dérive : du code plausible qui résout le mauvais problème
Spec-anchored contre spec-as-source
Les changements apportés par le Spec-Driven Development
Les immuables de la réalisation
La constitution du projet
Rôle du fichier de contexte : conventions, contraintes durables, politique de dépendances, exigences de test
AGENTS.md, CLAUDE.md et leurs équivalents : ce qui est réellement lu par l'agent
Écrire une contrainte que l'agent respecte au lieu d'une intention qu'il contourne
De la spécification aux tâches
La boucle en quatre temps : spécification, plan technique, découpage en tâches, implémentation
Ce qui appartient à la spécification et ce qui appartient au plan
Rappel de notation : critères d'acceptation exploitables, articulation avec la notation EARS
Le découpage en tâches : granularité, ordre, points de validation
Mise en œuvre sous GitHub Spec Kit : structure du dépôt, jeu de commandes, agents compatibles
Exécution et revue
Piloter l'implémentation tâche par tâche plutôt qu'en une passe
Réviser du code généré : ce que l'on regarde en premier, ce que l'agent rate systématiquement
Faire produire les tests : à quel moment, et sous quel contrôle
Appliquer la démarche à une base existante
Pourquoi le greenfield est l'exception et le brownfield la norme
Le flux par propositions de changement : décrire l'écart avant de l'implémenter
Reconstituer des spécifications sur les zones à forte valeur, sans documenter l'ensemble du code
Contenir la dérive quand la spécification et le code vivent en parallèle
Contraindre au lieu de recommander
Pourquoi une consigne dans un fichier de contexte est indicative, et ce qui la rend contraignante
Points de contrôle et automatismes de vérification dans le flux de développement
Détection de la dérive spécification / code
État durable sur projet long : gestion du contexte, isolation des travaux parallèles, reprise après interruption
Le standard d'équipe
Du geste individuel à la convention partagée : ce qui doit être écrit une fois pour toutes
Portabilité entre agents : le coût d'un standard couplé à un seul fournisseur
Coûts d'usage : ce qui les fait exploser, comment les mesurer
Traçabilité et audit dans un contexte réglementé
Les frameworks du marché comme études de cas : quels mécanismes ils implémentent, ce qu'ils coûtent, ce qu'on peut reproduire à la main
Savoir ne pas en faire
Les situations où la démarche coûte plus qu'elle rapporte : prototype, correctif isolé, exploration
Le schéma que la plupart des équipes finissent par adopter : explorer librement, puis spécifier ce qui passe en production
Plan d'action et premiers pas dans son propre contexte
Public cible :
Ce cours s'adresse aux développeurs, tech leads, architectes logiciels, ingénieurs QA impliqués dans l'automatisation, et Product Owners techniques.
Prérequis :
Avoir une pratique effective d'un agent de code (Claude Code, GitHub Copilot, Cursor, Gemini CLI ou équivalent) : savoir lancer une tâche, lire un diff, valider ou rejeter une proposition. Les formations DAIA (IA : Développeur Augmenté) ou CLOD (Claude Code) constituent la préparation attendue. La maîtrise de Git est indispensable.
J'évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Environnement : un dépôt Git par participant, un agent de code, GitHub Spec Kit. Fil rouge sur un service applicatif de taille réduite, fourni en deux états, vierge pour le jour 1, existant et imparfait pour le jour 2.
Atelier 1 - Rédiger la constitution d'un projet (1h, jour 1). Objectif : savoir formuler des contraintes de projet qu'un agent applique réellement, et mesurer l'écart entre une consigne suivie et une consigne ignorée. Chaque participant rédige la constitution du projet fil rouge, puis soumet une même demande d'implémentation à l'agent avant et après prise en compte du fichier. La mise en commun distingue les contraintes respectées, celles reformulées à leur avantage par l'agent, et celles purement ignorées.
Atelier 2 - Du besoin aux tâches (1h30, jour 1). Objectif : savoir dérouler la boucle complète sur une fonctionnalité et constater ce que le passage par le plan et les tâches évite. À partir d'un besoin exprimé en trois lignes, les participants produisent la spécification, le plan technique puis la liste de tâches ordonnée avec les commandes de Spec Kit, avec relecture imposée à chaque étape. La restitution compare les découpages obtenus.
Atelier 3 - Implémenter et réviser (1h30, jour 1). Objectif : savoir conduire une implémentation guidée par les tâches et réviser du code généré avec une grille explicite. Les participants font implémenter leurs tâches une par une. La grille de revue est construite collectivement au préalable : conformité au critère d'acceptation, respect de la constitution, tests discriminants, dépendances introduites, cas d'erreur traités. Chaque participant relève au moins deux écarts et les fait corriger.
Atelier 4 - Une évolution sur un dépôt existant (2h, jour 2). Objectif : savoir introduire la démarche dans une base de code qu'on n'a pas écrite, sans entreprendre de tout documenter. Les participants livrent une évolution fonctionnelle en trois temps : reconstituer la spécification de la seule zone concernée, décrire l'écart sous forme de proposition de changement, puis implémenter. Une modification de besoin est imposée à mi-parcours pour éprouver la mise à jour de la spécification et la traçabilité de la décision.
Date de mise à jour du programme : 19/08/2026
Dates et lieux
Période souhaitée
Lieux
Type d'affichage