Filum est livré avec un protocole de qualification d'installation : treize étapes que l'informatique du client déroule et signe. La plupart des éditeurs le rédigent. Nous l'avons exécuté, sur une installation réelle, du chargement de l'image jusqu'à la restauration d'une sauvegarde. Voici ce qu'il a trouvé — et pourquoi c'est une bonne nouvelle.
Chaque ligne indique l'étape qui a fait tomber le défaut, ce qu'il aurait coûté au client, et ce qui a été fait. Aucun n'aurait été trouvé sans dérouler la procédure : ni le contrôle du code, ni la construction de l'application, ni les cas de qualification ne s'exécutaient alors dans le conteneur livré.
L'installation s'arrêtait à la première étape technique, devant l'infogérant du client, un jour de mise en service. Aucun contrôle en amont ne pouvait le voir : ils s'exécutent tous en dehors du conteneur.
Traitement — Dépendances complétées, et un contrôle qui fait désormais échouer la CONSTRUCTION plutôt que le démarrage : l'erreur ne peut plus voyager jusqu'au client.
Le journal de démarrage — que l'infogérant conserve comme preuve d'installation — disait 1.0.0 pendant que l'écran affichait 1.2.0. Deux numéros pour une seule installation, dans un dossier qui doit rattacher chaque enregistrement à la version qui l'a produit.
Traitement — Une seule source, plus aucune valeur de repli. Et le protocole en fait maintenant un contrôle : relever la version au journal, la confronter à l'écran.
La procédure vérifiait que l'archive du volume portant les documents approuvés n'était pas vide. Le test répondait « vérifié » sur une archive de 86 octets, entièrement vide. Une sauvegarde rassurante et creuse — le défaut ne se serait découvert qu'à la première restauration.
Traitement — Contrôle d'existence des volumes AVANT la sauvegarde, puis comptage des enregistrements archivés. Le piège a été reproduit volontairement pour prouver que la nouvelle version l'attrape.
La sauvegarde arrête le service, copie, redémarre. Le script est mort au milieu : l'application est restée indisponible quatre minutes. Sur une tâche planifiée à deux heures du matin, elle l'aurait été jusqu'au matin.
Traitement — Le redémarrage est désormais garanti quoi qu'il arrive, et le guide rappelle qu'une sauvegarde dont personne ne lit le code de retour n'est pas une sauvegarde.
Le protocole demandait de confronter l'empreinte de l'archive reçue à celle communiquée par l'éditeur. Ni l'archive ni l'empreinte n'existaient, et l'étape sautait le seul contrôle qui attrape une livraison altérée en transit.
Traitement — Archive de livraison produite avec deux empreintes vérifiables sans Docker, et l'étape exige maintenant les deux : celle de l'archive avant chargement, celle de l'image après.
Le critère annonçait une redirection ; le logiciel affiche l'écran de connexion à la place du contenu. La protection est bien là — rien ne filtre — mais l'infogérant appliquant le texte à la lettre aurait consigné un écart sur un logiciel correct.
Traitement — Critère réécrit sur le comportement observé, dans les deux langues du protocole.
Le guide faisait charger un fichier au nom inventé et ne demandait aucune vérification d'empreinte avant chargement. Le client aurait suivi une procédure impossible dès sa première ligne.
Traitement — Section réécrite sur la livraison réelle, vérification d'empreinte incluse, avec l'avertissement de ne jamais reconstruire l'image pour la contrôler.
Les sept ci-dessus viennent de notre protocole. Les deux qui suivent viennent de quelqu'un d'autre — et c'est tout l'intérêt.
Les copies d'archivage des enregistrements figés sont produites au format PDF/A, celui qui garantit qu'un document se relira dans dix ans. Nous avions écrit notre propre contrôle de conformité en même temps, et il déclarait ces fichiers conformes.
Le 9 août 2026, nous avons fait tourner veraPDF — l'implémentation de référence, écrite par un consortium extérieur — sur une archive complète. Quatre enregistrements sur quinze étaient non conformes.
La cause tenait à un seul caractère : le « plus » en exposant de « Na⁺ », notation de chimie parfaitement ordinaire dans un dossier de diagnostic. La police embarquée ne le dessinait pas, et le fichier retombait sur un glyphe que le format interdit. Deux conséquences, dont aucune ne se voyait de l'intérieur : le document portait des métadonnées affirmant une conformité qu'il n'avait pas, et le lecteur voyait un rectangle vide là où l'enregistrement dit « Na⁺ ».
Notre contrôle ne voyait rien, et c'était prévisible : écrit par l'auteur du code, il en partage exactement les angles morts. Ce qu'on n'a pas pensé à produire, on ne pense pas non plus à le chercher. C'est l'argument de l'audit tiers, et il vaut pour un éditeur de logiciel comme pour un fabricant.
Ce qui en reste : le validateur de référence est désormais exécuté à chaque version, sur un document bâti pour le mettre en défaut. Et le harnais porte un témoin délibérément non conforme — si le validateur laisse passer le témoin, aucun autre résultat de l'exécution n'est retenu. « Quinze fichiers conformes » ne veut rien dire d'un outil qui ne sait plus dire non.
Corriger sept défauts ne vaudrait pas grand-chose si le huitième devait attendre le prochain client. L'exercice a surtout laissé des contrôles.
L'exécution est consignée dans un enregistrement daté et signé, dont l'empreinte est figée. Il est remis sur demande.
Le dossier de validation et le protocole IQ ont été retirés le 2 octobre 2026 : un audit interne y a relevé des affirmations que le code ne tenait pas. Leurs éditions corrigées accompagneront la version 1.3.0.
Un fournisseur qui affirme n'avoir aucun défaut affirme surtout n'avoir rien cherché. Ce que vous pouvez demander à un éditeur, ce n'est pas l'absence de défauts : c'est qu'il ait déroulé sa propre procédure, qu'il dise ce qu'il a trouvé, et qu'il vous montre ce qui empêche le prochain de passer.
C'est aussi la raison d'être du produit. Filum ne promet pas que vos dossiers seront parfaits : il fait en sorte qu'un écart se voie pendant que vous pouvez encore le traiter, plutôt que devant un auditeur.