C’est durant l’excellente unconférence JChateau, le 7 mars 2026, qu’a débuté l’aventure Vidocq. Les discussions allaient bon train sur l’IA (entre les débats sur la souveraineté et les nouveautés de Java 26) et sur l’arrivée d’un "nouveau" concept : le spec-driven development. Après avoir plaisanté sur la réinvention du cycle en V par la communauté dev, nous avons réalisé que des projets avec des spécifications en béton, il y en avait un gisement conséquent dans l’écosystème Java avec Jakarta EE et MicroProfile.

Contrairement à la plupart des frameworks qui posent leurs propres règles (comme Spring), ces specs définissent des contrats précis, vérifiables, et sont chacune assorties d’un harnais de tests d’acceptance redoutable : le TCK (Technology Compatibility Kit). Les documents de spécification plus les API plus les TCK constituent quelque chose d’assez unique dans le monde du développement. Ce mix constituait la spec ultime pour valider le spec-driven development avec un cas très concret : l’implémentation d’une des spécifications les plus ambitieuses de Jakarta EE : Contexts and Dependency Injection (CDI).

C’est de cette idée d’expérimentation qu’est né Vidocq.

L’implémentation de chaque spec a suivi le même rituel. Cette méthode n’a pas été inventée d’un coup, elle s’est construite au fur et à mesure de l’avancement de l’expérience CDI et a ensuite été propagée aux autres modules de Vidocq

Sébastien Le Prestre de Vauban était l’ingénieur militaire de Louis XIV, le bâtisseur de fortifications inexpugnables. Le nom s’imposait pour le container CDI : solide, sans faille, conçu pour tenir.

Le besoin pour MicroProfile était de n’implémenter que la partie Lite de la spec qui exclut les features liées aux EJB et au système d’extension legacy au profit des nouvelles Build Time Compatible Extensions apparues dans CDI 3.0.

Vauban, CDI 4.1 Lite : 774/774 tests TCK. 100 %.

La "forteresse" Vauban a mis une dizaine de jours à céder.

Lorsque le 774ème test est passé au vert, l’équipe a compris que le "jeu" de départ allait devenir plus sérieux. En effet, ce résultat validait tout le pari. Une IA pouvait implémenter une spécification Java Enterprise complexe, avec des contraintes inédites, et passer la suite officielle de tests sans une seule défaillance. Ce n’était plus une hypothèse.

La question naturelle après Vauban était : si ça marche pour CDI, jusqu’où peut-on aller ?

La réponse, construite module par module au fil des semaines, c’est Vidocq dans son état actuel : dix-neuf repos dont quinze modules indépendants couvrant l’intégralité du Core Profile et de MicroProfile.

La frise ci-dessous retrace cette construction, du prototype Capsule né à JChateau jusqu’à la sortie open source. Les dates correspondent au premier et au dernier commit de chaque dépôt.

Quinze modules. Une seule règle : passer la TCK.

180 000+ lignes de Java générées avec Claude Code sous contraintes.

Aucun test TCK désactivé. Aucune dépendance externe non justifiée. Aucune manipulation de bytecode à l’exécution.

Ces chiffres impressionnent, mais ils en cachent un autre, bien plus grand et bien plus ancien : celui des femmes et des hommes qui ont écrit, débattu et affiné ces spécifications pendant près de vingt ans. Vidocq n’invente rien de ce qu’il implémente ; il exécute, fidèlement et à toute vitesse, des contrats mûris par une communauté entière.

Les briques du Core Profile ne datent pas d’hier. CDI naît au milieu des années 2000 (JSR 299, finalisée fin 2009 avec Java EE 6), Jakarta REST (ex-JAX-RS) démarre en 2007, et JSON-P, JSON-B ou les annotations communes suivent dans les années 2010. Tout ce travail, d’abord mené au sein du Java Community Process, passe ensuite sous la gouvernance ouverte de la Fondation Eclipse à partir de 2017-2018. MicroProfile, lui, est fondé en 2016 pour porter cet héritage vers les microservices, et n’a cessé de s’enrichir depuis. Le Core Profile tel que l’implémente Vidocq est formalisé en 2022 avec Jakarta EE 10.

Rien que sur les dépôts publics de ces quinze spécifications, on dénombre près de 200 contributeurs identifiables, et ce décompte ignore les groupes d’experts JCP des années 2000, antérieurs à GitHub. Derrière ces noms : Red Hat, IBM, Oracle, Payara, Tomitribe, Microsoft et une communauté open source mondiale qui, release après release, a transformé des intentions en contrats vérifiables.

C’est tout le paradoxe heureux de Vidocq : une stack assemblée en quelques semaines par des développeurs augmentés ne tient debout que parce qu’elle s’appuie sur près de vingt ans de spécifications collectives. Le TCK qui sert d’arbitre, les API que l’on implémente, les contrats que l’on respecte : tout cela est l’héritage d’un travail colossal. Sans ces géants, Vidocq n’existerait tout simplement pas. S’il voit si loin, c’est qu’il se tient sur leurs épaules.

Même si la stack a démarré sous forme de défi, Vidocq est allé au-delà de la simple démonstration. C’est une implémentation production-grade de l’ensemble du Core Profile Jakarta EE et de MicroProfile, avec des contraintes architecturales que les frameworks mainstream n’ont pas encore posées.

La méthode, contraintes fortes + plan + guidage + TCK comme arbitre, est reproductible. Elle impose à l’IA une rigueur que les tests unitaires classiques ne garantissent pas. La TCK ne ment pas, ne tolère pas les approximations, ne s’adapte pas à ce que l’implémentation a envie de faire.

C’est peut-être la leçon la plus importante de Vidocq : l’IA est d’autant plus performante qu’elle a un juge objectif, externe, et inflexible. La spécification est ce juge.

Vidocq est à présent mis à disposition de la communauté avec une triple licence EUPL 1.2, EPL 2 et GPL 2.0. Il est possible de l’utiliser pour des projets personnels ou professionnels, de l’étudier, de le modifier et de le redistribuer.

Nous allons continuer à faire évoluer la stack en ajoutant au module d’intégration des outils facilitant la vie des développeurs. Une roadmap est en cours de construction pour les prochaines spécifications Jakarta EE, MicroProfile et le tooling. Vos idées et contributions sont bienvenues pour alimenter ces réflexions et leurs futures réalisations. Une opportunité pour vous mettre le pied à l’étrier sur le développement augmenté ?

Le code est disponible sur Codeberg. La méthode est documentée et réutilisable pour développer d’autres briques.

Bienvenue chez Vidocq !