Interviews

Emmanuel Cordente, SNCF Connect & Tech : « avec le Spec Driven Development, une vitesse multipliée par 2 à 4 »

Selon le directeur technique de SNCF Connect & Tech, avec le Spec Driven Development, « l’expression de besoins devient très mature, avant même d’aborder la phase de développement proprement dite ». (Photo : D.R.)

Pour le CTO de SNCF Connect & Tech, l'introduction de la GenAI dans les métiers du développement a d'abord débouché sur des gains incrémentaux. Mais l'arrivée de nouvelles méthodes, comme le Spec Driven Development, se traduit désormais par une accélération bien plus marquée.

PublicitéComptant environ 1300 employés, dont deux-tiers d'informaticiens, SNCF Connect & Tech, filiale technologique du groupe ferroviaire national, se confronte depuis près de trois ans à l'introduction de la GenAI dans tout le cycle de développement. Son directeur technique, Emmanuel Cordente, décrit toutefois la rupture, plus récente, apportée par une transformation plus radicale de l'approche et de la forme des équipes elles-mêmes, avec le Spec Driven Development (*).

SNCF Connect & Tech gère 250 projets en parallèle et ses équipes sont réparties sur trois sites : Paris, Nantes et Lille.

Comment l'IA s'est-elle peu à peu installée dans les environnements de développement de vos équipes ?

E.C. : Nous avons commencé à travailler avec l'IA au sein des environnements de développement dès la fin 2023, pour effectuer de premières expérimentations. Au début, les usages se concentraient sur l'auto-complétion, une approche facile d'accès pour les développeurs car elle ne modifie pas leurs façons de travailler, tout en permettant de produire du code plus rapidement. Nous avons généralisé une solution de ce type dès avril 2024.

Fin 2024 et début 2025, nous avons commencé à tester les agents, intégrés à l'intérieur de ces assistants de développement. Pour un développeur, le fait de donner des instructions à un agent qui édite le code - ce qu'on appelle le vibe coding - représente un changement d'habitude plus important. Et nous nous sommes rapidement heurtés aux limites de l'approche. Après un effet waou au démarrage, nous nous sommes en effet rendus compte que lorsqu'on veut travailler sur des applications complexes qui doivent être maintenues dans le temps, cette méthode ne fonctionnait plus trop bien. Dès qu'on veut dépasser le stade du prototype, on se heurte aux limites de taille des fenêtres de contexte. Une fois cette taille dépassée, l'agent perd des informations et on entre dans des boucles peu productives. Les retours des développeurs commençaient à devenir négatifs. Nous avions donc besoin d'organiser ce contexte, via une restructuration de la documentation, plutôt que d'expliquer à un agent par chat ce qu'il doit faire. Nous sommes donc revenus aux basiques ! Ce travail sur les spécifications techniques et fonctionnelles nous a amené au Spec Driven Development.

Comment avez-vous abordé ce virage vers cette nouvelle méthodologie ?

En octobre 2025, nous avons lancé notre premier projet pilote en la matière, un projet Greenfield, autrement dit un nouveau développement. Avec une équipe minimale, composée d'un Product Owner et d'un développeur. Nous voulions tester une manière de travailler radicalement différente de ce qui existait auparavant, pas juste une optimisation de nos méthodologies. Et nous avons utilisé le Spec Driven Development (SDD) tant sur le développement que sur le produit lui-même. Nous avons équipé le PO avec des agents lui permettant de travailler sa vision du produit, son expression de besoins, le prototypage, etc.

PublicitéSur cette première phase, nous avons pu mesurer la rapidité de ce mode de fonctionnement et surtout sa faculté à produire rapidement des maquettes. En 3 ou 4 minutes, un prototype est prêt, ce qui permet d'être très itératif lors de cette phase. Le premier bénéfice, c'est que l'expression de besoins devient très mature, avant même d'aborder la phase de développement proprement dite. Dans des approches plus classiques, parvenir à bien stabiliser le besoin nécessite souvent plusieurs sprints de deux à trois semaines, mobilisant toute l'équipe. L'effet induit, que nous n'avions d'ailleurs pas identifié au début, c'est que la qualité du premier livrable, la v1, est bien meilleure, car elle n'est pas passée par ces phases de refactoring dues au manque de maturité du besoin dans les approches classiques, tâtonnements qui mécaniquement créent du Legacy. Par ailleurs, la qualité documentaire a progressé avec cette approche : les IA génératives produisent des documents clairs et précis, que nous serions incapables de réaliser manuellement, à moins d'y consacrer énormément d'énergie.

Qu'en est-il sur la phase de développement proprement dite ?

Nous avons constaté un accroissement de la vitesse, là encore. Le développeur embarqué dans notre équipe SDD de deux personnes était un profil full stack expérimenté, couplé à des agents spécialisés sur les différentes composantes techniques, agents que nous avions construits à l'époque nous-mêmes faute d'offre standard sur le marché. Cette première expérimentation, menée au mois d'octobre dernier, a été prolongée par d'autres projets, mais nous avons basculé sur des approches Open Source qui se sont développées depuis, notamment via des frameworks comme BMad ou Spec Kit, portés par des communautés très actives.

Avez-vous estimé le gain apporté par l'approche Spec Driven Development ?

Nous avons surtout mesuré le gain en termes de vélocité : en fonction des activités, nous observons des facteurs multiplicateurs compris entre 2 et 4. Des accélérations importantes comparées à de l'auto-complétion ou au vibe coding, où les gains se chiffrent plutôt à 10 ou 15%.

Avez-vous généralisé cette approche SDD ?

C'est notre défi actuel. Les niveaux de maturité sont très différents d'une équipe à l'autre. Quelques projets travaillent déjà sur ces approches-là, même si la méthodologie elle-même n'est pas encore stable, le SDD continuant à évoluer. Avec les autres équipes, nous travaillons sur un niveau intermédiaire entre le vibe coding et le Spec Driven Development, où des agents s'appuient sur un contexte structuré, via des pratiques aujourd'hui standards, comme les skills ou les MCP. Un certain nombre d'agents locaux et spécialisés sont ainsi associés au projet et rendent le vibe coding beaucoup plus performant.

En la matière, les skills, apparues fin 2025 et inventées par Anthropic, constituent un virage important, avec un gain de qualité intéressant. Nous parvenons ainsi à injecter beaucoup de compétences dans nos agents sans saturer notre fenêtre de contexte. Nos équipes ont développé de nombreuses skills, mises à disposition des agents, selon les besoins. C'est un peu comme si un agent avait à sa disposition une bibliothèque, sans avoir à connaître le contenu de tous les livres y figurant. C'est plutôt sur cette approche que nous sommes en voie de généralisation, avec par exemple des places de marché de skills à destination des développeurs. Sur ce niveau-là, les gains peuvent approcher le x2 dans certains cas, et l'approche est bien adaptée à des projets existants, car les équipes n'ont pas besoin d'être transformées pour s'adapter au SDD. En effet, ce dernier requiert des équipes bien plus petites que les classiques pizza teams. On parle même désormais de sandwich teams.

« Même avec les augmentations [de tarifs], qui peuvent être de l'ordre d'une multiplication par 10, l'équation reste largement favorable. Mais la question du pilotage des coûts et de la valeur devient un enjeu d'entreprise. »

Cette automatisation croissante ne s'accompagne-t-elle pas d'une hausse des risques en matière de sécurité ?

Dans notre organisation, même s'il délègue une partie de son activité, le développeur reste le garant de ce qu'il produit. Concrètement, cela signifie qu'il relit tout ce qui est livré. Et la GenAI permet là encore d'aller plus loin sur la sécurité, via des agents spécialisés effectuant par exemple une pré-revue du code. En plus de détecter des schémas incorrects dans le code, d'autres agents peuvent aussi interpréter les résultats issus d'autres outils de sécurité déjà présents dans notre usine logicielle. Par exemple, nous avons déployé un agent qui récupère ces résultats, les analyse pour les développeurs et les guide dans les corrections.

L'augmentation récente des coûts des tokens remet-elle en causse cette stratégie de généralisation des agents ?

Jusqu'à présent, les coûts n'étaient pas un problème, car les modèles étaient fortement subventionnés par les éditeurs. Depuis quelques semaines, nous avons effectivement le sentiment que c'est fini. Nous avons l'impression de payer davantage le coût réel, ce qui permet de se reposer la question de la valeur. Et des nouvelles limites à instaurer pour éviter les usages incorrects, en fonction du niveau de maturité des équipes.

Nous constatons, en effet, que plus cette maturité progresse, plus la valeur augmente. Notre sentiment général, c'est que, même avec ces augmentations qui peuvent être de l'ordre d'une multiplication par 10, l'équation reste largement favorable. Mais la question du pilotage des coûts et de la valeur devient un enjeu d'entreprise. Nous formons ainsi nos collaborateurs sur les usages frugaux : le FinOps, à l'image de ce qui existait sur le cloud, l'optimisation des requêtes ou encore l'utilisation de modèles plus petits.

* L'approche Spec Driven Development place les spécifications au coeur du processus de développement logiciel, en partant du principe qu'avec une technologie capable de générer le code instantanément, la valeur de l'ingénierie se déplace de la syntaxe vers la sémantique.