Vous avez demandé un outil, et 10 minutes plus tard une spécification de 15 pages vous attend. Le document est structuré, complet en apparence et rédigé sans une faute. On vous demande de le valider pour lancer le développement.
L’IA sait aujourd’hui rédiger une spécification seule, et elle le fait très bien. Le risque principal n’est donc plus d’avoir une spécification bâclée. Il tient à la personne qui commande le document et qui le valide. Si elle ne comprend pas ce qu’il engage, le projet avance vite dans une direction que personne n’a choisie.
Je travaille en ce moment pour un acteur réglementé de la finance. Sur ce projet, 2 décisions pèsent davantage que toutes les lignes de code. Un humain doit toujours valider ce que l’outil propose. Les modèles d’IA, les moteurs qui produisent les réponses, doivent passer par la plateforme que gère la DSI, la direction informatique. Si ces décisions ne sont pas écrites dès le départ, l’outil risque de ne respecter ni la réglementation ni les règles internes.
Ce qui compte vraiment dans une spécification tient à 3 choses : les décisions à y écrire, les personnes qui doivent la juger et la façon de la relire.
Qu’est-ce que le spec-driven development
Le spec-driven development, ou développement piloté par la spécification, consiste à écrire ce que le logiciel doit faire avant de le faire coder par l’IA. La spécification, le document qui décrit ce comportement, devient la référence commune : l’humain la relit, l’IA s’y réfère.
La méthode compte en général 4 étapes. GitHub, la principale plateforme où les développeurs conservent leur code, les a décrites en septembre 2025 en publiant son outil Spec Kit. Le schéma ci-dessous les reprend, avec ce qui revient à l’IA et ce qui revient à un humain.
L’enchaînement
À chaque étape, l’IA produit et un humain juge
-
Étape 1 Spécifier
Décisions engageantesCe que l’IA produit
Elle rédige le comportement attendu : parcours, règles, cas d’erreur, critères de réussite.
Ce qu’un humain juge
Le document décrit-il bien le besoin, et les décisions qu’il contient ont-elles été prises par quelqu’un ?
-
Étape 2 Planifier
Décisions engageantesCe que l’IA produit
Elle propose les choix techniques et l’organisation du code.
Ce qu’un humain juge
Ces choix respectent-ils ce que votre entreprise accepte d’héberger et de maintenir ?
-
Étape 3 Découper
Ce que l’IA produit
Elle transforme le plan en tâches petites, que l’on peut vérifier une par une.
Ce qu’un humain juge
Chaque tâche a-t-elle une définition claire de « terminé » ?
-
Étape 4 Réaliser
Ce que l’IA produit
Elle écrit le code et lance les tests, tâche après tâche.
Ce qu’un humain juge
Le logiciel fait-il ce que décrit la spécification ?
Vous gardez un rôle précis dans ce déroulé, que GitHub résume ainsi : l’IA produit les documents, et vous vous assurez qu’ils sont justes. La rédaction ne vous coûte presque plus rien, alors que la relecture vous revient entièrement.
Le vibe coding désigne la pratique inverse : décrire une envie à l’IA, regarder le résultat, puis corriger à la volée. Elle convient pour explorer une idée. Son prix se paie dès que le logiciel doit durer, recevoir des données réelles ou s’insérer dans un système existant.
Dans ma pratique, j’applique cet enchaînement sur mes projets. Le récit d’une application mobile de 85 écrans réécrite pour Android montre ce déroulé sur un projet réel.
L’IA rédige très bien une spécification, et c’est le piège
Une IA produit aujourd’hui une spécification complète à partir de 3 phrases. L’IA propose les écrans, les règles, les cas d’erreur et les critères de test. Elle pose même des questions pertinentes quand la demande est floue.
Je le constate sur mes projets. Le temps de rédaction n’est donc plus une raison valable de se passer d’une spécification.
Le piège tient à ce que le document ne montre pas. Quand une information manque, l’IA ne laisse pas de blanc : elle choisit. Chaque choix paraît raisonnable pris seul, et la plupart ne sont pas signalés comme des choix.
Je le mesure sur mes tickets de développement, les fiches qui décrivent chaque modification. Je les traite tantôt avec un skill, une fiche d’instructions donnée à l’IA qui m’oblige à passer par une spécification, tantôt sans. La différence tient à la finesse de la conception : avec la spécification, chaque choix est posé par écrit ; sans elle, l’IA prend beaucoup de décisions par défaut.
Un choix par défaut n’est pas mauvais en soi. Il n’est simplement pas toujours adapté à votre situation. Les modèles ont en plus leurs habitudes : pour l’interface, les écrans que voit l’utilisateur, ils proposent très souvent le langage JavaScript avec l’outil React, et Python pour la partie serveur, celle qui tourne en coulisse. Demandez à une IA avec quoi construire une application, et elle vous répondra souvent Supabase, un service en ligne qui fournit la base de données et la gestion des comptes.
Chaque choix technique a pourtant des conséquences, et j’en retiens 3 exemples dans ma pratique :
- L’interface. J’écris les miennes exclusivement en TypeScript, un langage plus strict que JavaScript, qui repère une partie des erreurs avant que le programme ne tourne. Je l’ai choisi pour la fiabilité, pas pour faire joli.
- La partie serveur. Je retiens un langage que les équipes en place sauront maintenir. Un langage que personne ne sait gérer chez vous posera des problèmes plus tard.
- Les données. Un service comme Supabase place vos données chez un fournisseur de plus, avec ses propres réglages de sécurité : un mauvais réglage suffit à exposer une base. Certains projets n’en ont aucun besoin.
J’en ai vu une version miniature sur cette application mobile. Faute de trouver l’écran d’origine à reproduire, l’IA en a inventé un. Les consignes du projet contiennent depuis une règle écrite : ne jamais inventer un écran qui n’existe pas. Le décryptage sur le harness engineering range ce type de raté parmi les signes d’un harness incomplet.
Le texte est donc sans faute, et les décisions que vous n’avez pas prises l’ont été à votre place. Dans une spécification écrite à la main, un point non traité se voyait plus souvent : il manquait. L’IA remplit ce vide, et la qualité apparente du texte invite à signer.
Votre signature pèse pourtant plus lourd qu’avant, parce que l’IA va construire à partir de ce document, et qu’elle va le faire vite.
La personne qui fait faire la spécification doit donc comprendre ce qu’elle valide. Si elle signe sans pouvoir expliquer les choix du document, elle court à la catastrophe : un logiciel entier, bâti en quelques jours sur des décisions que personne n’a examinées.
Les décisions qu’une spécification doit porter et que l’IA ne prendra pas
Sur la mission que je mène pour cet acteur de la finance, 2 décisions cadrent toute la conception de l’outil.
La première porte sur la validation. L’activité est réglementée : un humain doit toujours valider. Vous ne pouvez pas traiter cette obligation comme un réglage de fin de projet. Un outil qui propose puis attend un accord n’a ni les mêmes écrans, ni les mêmes données conservées, ni le même historique qu’un outil qui agit seul.
La seconde porte sur le contrôle des modèles d’IA. Le groupe veut que ses modèles d’IA soient gérés en interne, par la plateforme que la DSI administre. Microsoft Foundry, l’ancien Azure AI Foundry, est un exemple de ce type de plateforme : la DSI y choisit les modèles autorisés, règle les accès et suit les usages depuis un seul endroit.
Aucune de ces 2 décisions n’apparaît dans une demande de 3 phrases. Si personne ne les écrit, la spécification en retient d’autres à leur place.
Je retrouve souvent un troisième oubli : ce qui existe déjà chez vous. Vous lancez un projet A qui devra s’intégrer à un projet B. Vous donnez à l’IA tout le contexte du projet A, et elle conçoit quelque chose de très bien. Une partie des données existait pourtant déjà dans le projet B. Il fallait les mettre en commun, et la spécification les recrée à l’identique.
Le comparatif
La même spécification, sans consigne puis avec
Spécification fonctionnelle
Ce que fait la fonctionnalité
Sans consigne
« L’outil traite la demande et envoie la réponse au client. »
Votre consigne
« L’outil ne décide jamais seul. »
La spécification écrit alors
« L’outil prépare une proposition. Un gestionnaire la valide avant tout envoi, et son nom est enregistré avec la date. »
Modèles d’IA
Où tournent les modèles d’IA
Sans consigne
« Les réponses sont générées par un appel direct au service d’OpenAI, avec une clé créée par le développeur. »
Votre consigne
« Utilise uniquement la plateforme d’IA administrée par notre DSI. »
La spécification écrit alors
« Tous les appels à un modèle passent par la plateforme interne, avec les modèles que la DSI autorise. »
Stack technique
Avec quels langages et quels serveurs
Sans consigne
« Interface en JavaScript avec React, serveur en Python, données dans Supabase. »
Votre consigne
« Utilise TypeScript et React pour l’interface, le langage serveur que notre équipe maintient déjà, et notre base de données. »
La spécification écrit alors
« Interface en TypeScript avec React. Serveur dans le langage de l’équipe en place. Base de données hébergée par la DSI. »
Données
Quelles données partent vers le modèle
Sans consigne
« Le dossier complet du client est transmis au modèle pour obtenir la meilleure réponse. »
Votre consigne
« N’envoie au modèle ni nom, ni coordonnées bancaires. »
La spécification écrit alors
« Seuls le type de demande et le montant sont transmis au modèle. Le nom et les coordonnées bancaires restent dans l’outil. »
Cœur métier · ne pas refaire l’existant
Comment se connecter au système existant
Sans consigne
« Création d’une liste des clients, avec leur nom, leur adresse et leur contrat. »
Votre consigne
« Les clients existent déjà dans notre outil de gestion. Ne les recrée pas : connecte-toi à l’existant. »
La spécification écrit alors
« Le nouvel outil se connecte à l’outil de gestion pour lire les clients. Aucune donnée n’est dupliquée. »
Passez en revue les 5 questions de ce comparatif avant toute spécification. Leur réponse existe chez vous, dans une règle interne, un contrat ou la tête d’un responsable. L’IA n’y a pas accès tant que personne ne la lui écrit.
Écrivez ces réponses avant de générer la spécification. Fournies en entrée, elles orientent tout le document. Ajoutées en correction, elles obligent à reprendre ce qui a été bâti sans elles.
Ce que coûte une spécification mal jugée : la poubelle ou la reprise
Un oubli de ces décisions se découvre souvent tard, au moment de présenter l’outil à la DSI qui doit l’héberger. Le logiciel fonctionne et la démonstration convainc. La DSI pose alors 2 questions : où tournent les modèles, et sur quoi l’outil est-il bâti ?
Le projet connaît ensuite l’une de ces 2 issues :
- La poubelle. Les langages et les serveurs retenus ne correspondent à rien de ce que la DSI accepte d’héberger. L’outil ne sera pas mis en service, quelle que soit sa qualité.
- La reprise. L’outil peut être adapté, au prix d’un travail important pour le rebrancher sur la plateforme interne et revoir tout ce qui en dépend.
Rien n’empêchait pourtant de fixer ces choix techniques et de baliser le cadre dès le début. Au moment de la spécification, changer une décision coûte une ligne de texte.
Les 2 issues
La même décision coûte une ligne au départ, un projet à la fin
Décidé au départ
- Les contraintes sont écrites avant la spécification.
- La DSI lit les choix techniques et les accepte.
- L’IA construit dans le cadre attendu.
Le coût de la décision : quelques lignes de texte et une relecture.
Découvert à la fin
- La spécification est générée et validée sans question.
- L’IA construit vite, sur des choix que personne n’a faits.
- La DSI découvre l’outil au moment de l’accueillir.
Le coût de la décision : un outil refusé, ou une large part du travail à refaire.
Je n’ai pas subi ce scénario sur mes projets, parce que ces choix y sont écrits dès le départ. La spécification sert justement à écarter ce risque : ce n’est pas un souvenir que je vous raconte.
L’IA rend cet écart plus brutal. Elle produit beaucoup de code en peu de temps, donc beaucoup de code à reprendre quand la direction de départ était mauvaise.
J’ai vu l’effet inverse sur l’application mobile. Le projet a tenu en 3 mois, de juin à août 2026, avec les outils d’IA de cette période, quand la version d’origine avait pris 2 ans. L’application existait déjà, mais une grande part de l’écart tient au cahier des charges, le document qui décrivait le besoin : toutes les décisions y étaient déjà prises. Presque chaque fois que l’IA posait une question, la réponse existait déjà.
Prévoyez de la même façon la validation par un humain. Ajouter après coup une étape où une personne approuve chaque proposition oblige en général à refaire les écrans, les droits d’accès et l’historique des décisions. Écrite dès la spécification, cette étape reste une contrainte parmi d’autres.
Qui doit juger la spécification : le métier, la DSI et le responsable technique
Vous ne pouvez pas confier ce jugement à une seule personne, parce que les décisions à vérifier relèvent de 3 savoirs différents.
Les responsabilités
3 lecteurs, 3 questions différentes sur le même document
Le métier
Ce qui est jugéLes règles, les cas particuliers, ce qui se passe quand une information manque, et qui valide quoi.
Sa questionEst-ce bien notre façon de travailler, y compris les jours où ça se passe mal ?
Le responsable technique
Fait le lien entre le métier et la DSI
Ce qui est jugéLa cohérence de l’ensemble, le découpage, les critères mesurables et les choix restés implicites.
Sa questionLa technologie retenue correspond-elle aux besoins du métier ?
La DSI
Ce qui est jugéL’endroit où tournent les modèles d’IA, l’hébergement, les données qui circulent et les accès.
Sa questionSavons-nous maintenir ce qui est décrit, et les règles de sécurité sont-elles respectées ?
Le métier vérifie que les règles décrites sont bien les siennes. Il regarde surtout les cas qui sortent de l’ordinaire : une information manquante, une exception accordée à un client, une demande arrivée hors délai. L’IA propose une réponse à chacun de ces cas, et seul le métier sait si elle est juste.
Votre DSI doit lire le document avant le début du développement. Je recommande de lui soumettre d’abord les choix techniques proposés par l’IA, sans attendre la spécification complète. Ils tiennent en peu de pages, et leur relecture réduit fortement le risque d’un refus en fin de projet.
Le responsable technique porte la part la plus difficile : repérer ce que le document a décidé sans le dire. Il compare la spécification à vos contraintes, pose les questions que l’IA n’a pas posées et refuse un critère que personne ne sait mesurer.
Sur l’application mobile, ma spécification exigeait par exemple des résultats strictement identiques à ceux de l’application d’origine, sur 100 séries de données de test. Un critère de ce type se vérifie. « L’application doit être fiable » ne se vérifie pas.
Vous pouvez tenir le rôle du responsable technique vous-même à une condition : savoir expliquer chaque choix du document à quelqu’un d’autre. Si ce n’est pas le cas, faites relire la partie technique par une personne qui le peut, dans votre équipe ou à l’extérieur.
Un signal d’alerte se repère facilement : une spécification validée en quelques minutes, sans une seule question en retour, n’a pas été jugée.
Comment relire une spécification écrite par l’IA
Vous n’avez pas besoin de relire chaque ligne avec la même attention. Une spécification générée fait souvent des dizaines de pages, et l’IA ne suit pas toujours toutes les consignes : une relecture qui survole tout ne repère rien. Concentrez donc l’effort sur les décisions qui engagent le projet.
Suivez ces 6 étapes dans l’ordre, avant d’autoriser le développement :
- 1Écrivez vos contraintes avant de générer. Tenez sur une page les 5 réponses du comparatif : ce que fait la fonctionnalité, où tournent les modèles, quelle stack technique, c’est-à-dire quels langages et quels serveurs, quelles données, et comment se connecter à l’existant. Donnez cette page à l’IA en même temps que le besoin.
- 2Ajoutez toutes les contraintes métier. Faites-les écrire par ceux qui connaissent l’activité : les règles à respecter, les obligations réglementaires, les délais, les exceptions accordées à certains clients, ce qui se passe quand une information manque. L’IA ne les devinera pas, et ce sont elles qui rendent l’outil utilisable.
- 3Faites lister les choix que l’IA a faits seule. Demandez-lui la liste des hypothèses qu’elle a retenues faute d’information. Chaque ligne est une décision à confirmer ou à corriger. Cette liste reste incomplète : elle aide la relecture, elle ne la remplace pas.
- 4Soumettez les choix techniques à votre DSI. Faites-le avant que le développement commence. Un refus à ce stade se règle en modifiant le document.
- 5Vérifiez que chaque critère se mesure. « L’outil doit être fiable » n’est pas un critère. « Chaque règle métier de la spécification est vérifiée par au moins un test automatique » et « l’outil répond en moins de 2 secondes avec 200 utilisateurs simultanés » en sont : vous pouvez constater s’ils sont atteints. Un critère que personne ne sait tester ne protège personne.
- 6Explicitez qui est responsable de chaque décision. Écrivez dans la spécification qui tranche quoi : le métier pour les règles, la DSI pour l’hébergement et la sécurité, le responsable technique pour les choix techniques. L’IA ne doit rien trancher seule : elle exécute, et chaque choix qu’elle propose a un responsable humain. Notez aussi la date et les questions posées pendant la relecture.
Votre spécification devient alors un document que quelqu’un a jugé, au lieu d’un texte que tout le monde a laissé passer.
Auteur de l’article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes sur le spec-driven development
Qu’est-ce que le spec-driven development ?
C’est une méthode de développement avec l’IA : vous faites écrire une spécification, le document qui décrit ce que le logiciel doit faire, avant de faire écrire le code. L’IA s’appuie ensuite sur ce document pour planifier, découper et réaliser le travail. La spécification devient la référence commune entre vous et l’IA.
Quelle différence entre une spécification et un cahier des charges ?
Le cahier des charges décrit votre besoin pour choisir et engager un prestataire. La spécification du spec-driven development est le document de travail que l’IA lit pour produire le code. Elle descend jusqu’aux règles, aux cas d’erreur et aux critères de test, et elle évolue avec le logiciel. Un bon cahier des charges fournit les décisions que la spécification doit ensuite porter.
Quelle différence entre spec-driven development et vibe coding ?
Le vibe coding consiste à décrire une envie à l’IA, à regarder le résultat et à corriger à la volée. Il convient pour explorer une idée ou montrer un prototype. Le spec-driven development fixe d’abord par écrit ce qui est attendu, ce qui convient à un logiciel qui doit durer et s’insérer dans votre système. Les risques d’un outil construit sans cadre sont détaillés dans le décryptage sur les outils internes construits avec l’IA.
Faut-il un outil comme Spec Kit ou Kiro ?
Vous pouvez appliquer la méthode sans eux. Spec Kit, publié par GitHub, et Kiro, proposé par Amazon, organisent chacun les étapes à leur manière. Ce qui compte est l’enchaînement et la relecture à chaque étape. Pour une petite correction, un outil complet est souvent disproportionné.
L’IA peut-elle écrire la spécification seule ?
Elle peut la rédiger seule, et elle le fait bien. Elle ne connaît en revanche ni vos obligations, ni les règles de votre DSI, ni vos arbitrages internes tant que personne ne les lui écrit. Sans ces informations, elle retient des choix par défaut. Vous devez donc lui fournir vos contraintes, puis juger le document obtenu.
Qui valide la spécification dans une ETI ?
La validation demande 3 regards : le métier pour les règles et les cas particuliers, la DSI pour l’hébergement, les modèles d’IA et les données, et un responsable technique pour la cohérence d’ensemble. Désignez nommément la personne qui donne l’accord final. Si la DSI refuse souvent vos projets, le décryptage sur le refus d’un outil métier détaille ce qu’elle attend.
Sources et documentation
Les retours de terrain présentés ici viennent de ma pratique. La mission en environnement réglementé est en cours et volontairement anonymisée. Les phrases du comparatif sont des exemples rédigés pour l’illustration. Les références suivantes ont été consultées le 2 octobre 2026.
Retrouvez tous les Décryptages pour préparer vos décisions de développement et de direction technique.