Vidocq n’est pas qu’un runtime : c’est un manifeste pour une informatique européenne, ouverte et maîtrisée. Le projet est hébergé sur Codeberg, une forge associative européenne, et publié sous des licences ouvertes dont l’EUPL, la licence publique de l’Union européenne.

Cette filiation s’affiche jusque dans les noms de code des modules, qui rendent hommage à des figures du patrimoine scientifique et culturel européen. Vauban, l’ingénieur des fortifications de Louis XIV, donne son nom au conteneur CDI, solide et sans faille. Chappe, inventeur du télégraphe optique, nomme le serveur HTTP écrit from scratch. Cassini (REST), Champollion (JSON), Ravel (Config), Cervantes (JWT), Cyrano (Rest Client) ou Humboldt (Telemetry) prolongent cette galerie. Et au sommet, Vidocq, premier directeur de la Sûreté nationale, qui connaît les spécifications de l’intérieur pour mieux les honorer.

Vidocq n’invente aucun framework et n’impose aucune règle maison. Il implémente fidèlement des standards ouverts : CDI, Jakarta REST, JSON-P/B, Config, Servlet, et huit spécifications MicroProfile.

La preuve n’est pas déclarative, elle est mesurée. Chaque module est confronté au TCK (Technology Compatibility Kit), la suite de tests d’acceptance officielle de chaque spécification, l’arbitre impitoyable de la conformité.

Aucun test TCK désactivé. Choisir Vidocq, c’est choisir un standard, pas un fournisseur : vos applications restent portables, sans verrou propriétaire.

La plus grande surface d’attaque d’une application moderne, c’est sa chaîne de dépendances. Log4Shell l’a rappelé brutalement : une faille dans une bibliothèque transitive, et c’est tout l’écosystème qui tremble.

Vidocq prend le problème à la racine avec une règle radicale : zéro dépendance externe. Uniquement les API Jakarta et MicroProfile, et du Java pur.

Le résultat : une chaîne d’approvisionnement logicielle réduite à sa plus simple expression, auditable de bout en bout, et un démarrage natif sans surprise.