Reportage sur la construction d’un système logiciel avec l’intelligence artificielle — du premier prompt au premier prototype fonctionnel.
🔗 Code source du prototype : github.com/dmissud/biblioCQRS — tag First_IT
Le projet, en deux phrases
Je forme des informaticiens depuis des années — analyse métier, Babok, IREB, architecture logicielle. J’ai toujours utilisé le même exemple pour illustrer mes cours : une bibliothèque. Simple à comprendre, suffisamment riche pour démontrer des principes complexes. Cette fois, j’ai voulu aller plus loin : construire réellement le système, en direct, avec l’IA comme partenaire de développement. Et en documenter chaque étape.
BiblioCQRS est né de là. Un système de gestion de catalogue de bibliothèque, construit sur une architecture hexagonale, avec CQRS, Event-Driven Architecture et Apache Kafka. Le domaine est volontairement connu. Ce qui m’intéresse, c’est la méthode.
Le cadre avant tout
Avant d’écrire une seule ligne de code, j’ai posé le cadre à Gemini. Pas en lui demandant de « faire une application de bibliothèque ». En lui dictant les contraintes architecturales une par une :
« Nous allons commencer par poser les bases de l’objectif et des règles. Tout ce que nous réalisons doit suivre le TDD strict avec une approche via BDD. Mise en œuvre d’une approche style boîte noire sur la partie domaine/use case et suivre les principes de l’architecture hexagonale. »
Gemini a répondu positivement, a récapitulé les quatre principes — TDD, BDD, boîte noire, hexagonale — et a demandé par quel cas d’usage commencer. Bon début.
J’ai ensuite ajouté la couche CQRS et le choix d’infrastructure :
« Autre principe d’architecture que je veux que tu notes. Je veux faire une architecture CQRS. […] Je suis dans un état d’esprit de démonstration de bonne pratique, une base comme Postgres me va. »
Et là, Gemini a fait ce que font toutes les IA : il a immédiatement proposé trois options pour la gestion des événements — in-memory, message broker, event sourcing — avec des sous-questions sur le langage, l’écosystème, le niveau de complexité souhaité. Utile, mais déjà une légère dérive vers l’exhaustivité.
J’ai tranché net : Java Spring Boot, Maven multi-modules, Kafka, Docker Compose. Et on passe à la suite.
Le premier piège : l’IA qui veut tout faire
C’est là que ça devient intéressant. J’avais exposé le domaine métier : un ouvrage défini par son ISBN, son titre, son auteur. Des exemplaires physiques. Chaque exemplaire avec une localisation — salle, étagère, position. J’avais précisé que nous étions dans une bibliothèque, que les exemplaires comptaient autant que les ouvrages.
Gemini a produit son premier scénario BDD :
Given que l’ouvrage avec l’ISBN « 978-2-07-036822-8 » (« 1984 », George Orwell) n’existe pas dans notre catalogue
When le bibliothécaire référence cet ouvrage avec 1 exemplaire situé en « Salle A », « Étagère 2 », « Position 15 »
Then l’ouvrage est ajouté au catalogue
And 1 exemplaire est créé et assigné à ce lieu de stockage
Scénario propre. Bien formulé. Et pourtant, j’ai freiné.
« Je trouve ce premier scénario pas mal mais très riche pour une approche par baby step. Peut-être faire des étapes plus courtes pour une implémentation progressive. »
C’est le réflexe du formateur. Un scénario qui mêle la création d’un ouvrage ET l’ajout d’un exemplaire ET sa localisation, c’est trop pour une première itération TDD. Si quelque chose ne passe pas, on ne sait pas où chercher. Le baby step, c’est la règle d’or : une seule chose à la fois, une seule raison d’échouer.
Gemini a immédiatement compris et a découpé en trois étapes :
- Baby Step 1 : Référencer un ouvrage abstrait — ISBN, titre, auteur. Rien d’autre.
- Baby Step 2 : Refuser un doublon d’ISBN — la règle métier d’unicité.
- Baby Step 3 : Ajouter un exemplaire avec son lieu de stockage à un ouvrage existant.
Trois scénarios. Trois boucles TDD distinctes. Trois raisons différentes d’échouer — et donc de comprendre.
Ce que ça révèle sur l’IA
L’IA ne résiste pas à l’envie de livrer un système complet. Elle confond « montrer sa valeur » avec « tout faire tout de suite ». Laissée sans contrainte, elle produit du code riche, fonctionnel en apparence, mais monolithique — difficile à relire, impossible à tester proprement, et surtout en contradiction directe avec les principes qu’elle vient d’accepter. Vous lui demandez du TDD, elle fait du code. Vous lui demandez des baby steps, elle vous propose une feature entière.
Ce n’est pas un défaut de l’IA. C’est sa nature : elle optimise pour la complétude, pas pour la discipline. C’est au développeur de l’arrêter.
Et pour l’arrêter, il faut savoir où on veut aller.
La documentation comme garde-fou
En parallèle du code, j’ai imposé une règle : chaque itération doit enrichir la documentation fonctionnelle et architecturale. Pas après coup — en continu.
J’avais demandé à Gemini de produire une documentation structurée selon les principes du Babok : vision produit, parties prenantes, décomposition des objectifs, use cases. Mais pas d’un coup. Étape par étape, en restant strictement dans le périmètre de ce qui est implémenté.
« Notons comme une règle projet de toujours mettre à jour la documentation fonctionnelle. »
La doc n’est pas optionnelle. Elle n’est pas un livrable de fin de projet. C’est un miroir du code — elle doit refléter exactement ce qui existe, ni plus ni moins.
Résultat : à la fin du premier prototype, nous avions une documentation fonctionnelle structurée (vision, parties prenantes, arbre d’objectifs, glossaire métier, use cases) et une documentation d’architecture (hexagonale, CQRS, modules Maven, infrastructure). Les deux parfaitement alignées avec ce qui tourne réellement.
Ce qui a vraiment été construit
En quelques heures de dialogue dirigé, voici ce que le prototype contient :
Côté Command (écriture) :
Un domaine pur en Java — l’agrégat Ouvrage, ses entités Exemplaire, son value object LieuStockage. Trois scénarios BDD verts. Un adaptateur PostgreSQL via Spring Data JPA. Une publication d’événements vers Kafka (OuvrageReferenceEvent, ExemplaireAjouteEvent) encapsulée dans l’implémentation du repository — le domaine ne sait pas que Kafka existe.
Côté Query (lecture) :
Un consumer Kafka qui projette les événements dans une vue dénormalisée catalogue_view — ISBN, titre, auteur, nombre d’exemplaires. Un endpoint REST GET pour le frontend.
Le frontend :
Une application Angular 17 avec Material Design, trois facettes : consultation du catalogue en direct, référencement manuel d’ouvrage, et un tableau de bord de test qui déclenche une injection automatisée de quinze requêtes en rafale pour observer la propagation des événements dans Kafka.
L’infrastructure :
Un docker-compose.yml qui orchestre PostgreSQL, Zookeeper et Kafka. Deux applications Spring Boot indépendantes — command sur le port 8082, query sur le port 8083.
La thèse qui émerge
On entend souvent que l’IA va remplacer les développeurs. Cette expérience suggère l’inverse : elle rend la maîtrise des cadres plus indispensable que jamais.
Un développeur sans culture d’analyse métier, sans réflexe de découpage itératif, sans connaissance des principes architecturaux — ce développeur va se noyer dans ce que l’IA lui propose. Il va accepter le premier scénario trop riche. Il va laisser l’IA câbler le Kafka dans le domaine. Il va se retrouver avec un prototype qui fonctionne et qu’il ne comprend pas.
L’IA est un accélérateur formidable sur les tâches longues et répétitives : écrire des scénarios BDD, générer le squelette Maven, produire les entités JPA, configurer Spring Kafka. Ces tâches qui prenaient des heures se font en minutes.
Mais l’accélérateur ne sait pas où aller. C’est vous qui tenez le volant.
Épisode 2 : L’architecture sort de terre — comment guider l’IA pour qu’elle respecte les frontières de l’hexagone.
Laisser un commentaire