Formats de fichiers propriétaires : rétro-documenter pour migrer les données

Le 2 mai 2012, la Cour de justice de l'Union européenne juge, dans l'affaire SAS Institute (C-406/10), que ni la fonctionnalité d'un programme, ni son langage de programmation, ni le format de ses fichiers de données ne constituent une forme d'expression protégée par le droit d'auteur¹. Pour une DSI dont les données dorment dans un format maison, cet arrêt pose la base d'une migration : comprendre le format pour en extraire vos propres données.

Le vrai blocage d'une migration

Une équipe réécrit des écrans et des traitements. Elle ne peut pas réécrire vingt ans de données : elles doivent passer d'un système à l'autre sans perte ni altération. Tant que le format est documenté, ou qu'un pilote standard le lit, la question reste technique. Elle devient bloquante quand l'application range ses données dans des fichiers binaires maison, des exports dans un format que seul son éditeur connaît, ou des fichiers de configuration chiffrés de façon artisanale.

Le cas se présente souvent sur les stacks legacy et sur les applications dont l'éditeur a disparu. Rétro-documenter le format devient alors la première étape du projet, avant même le choix de la stack cible.

Ce que dit le droit européen

L'arrêt SAS Institute juge que le format des fichiers de données n'est pas une forme d'expression du programme protégée à ce titre, ce qui ne vaut pas pour le code qui les lit et les écrit. La Cour réserve toutefois qu'un format puisse être protégé comme œuvre, au titre de la directive 2001/29/CE, s'il est original. La directive 2009/24/CE, transposée à l'article L122-6-1 du Code de la propriété intellectuelle, encadre par ailleurs la décompilation de ce code : correction d'erreurs par l'acquéreur légitime, observation du fonctionnement, interopérabilité sous conditions strictes².

Le point d'attention pratique : étudier des fichiers de données que vous possédez se situe sur un terrain plus sûr que décompiler le programme qui les produit. Si la compréhension du format exige de lire le code de l'application, vous entrez dans le régime de la décompilation, détaillé dans décompiler pour interopérer et dans le hub clean-room ou reverse engineering. Votre juriste tranche, au regard de votre contrat de licence. Si le format est chiffré ou protégé par une mesure technique, le contourner peut relever d'autres règles encore : point à lui soumettre avant de commencer.

La méthode par échantillons connus

Constituez d'abord un jeu de fichiers dont vous connaissez le contenu. Saisissez dans l'application d'origine des enregistrements choisis : un client, puis le même avec un nom plus long, une date différente, un montant négatif, un champ vide. Chaque fichier produit diffère du précédent d'une seule valeur, et la comparaison octet par octet révèle où et comment cette valeur est stockée.

Cartographiez ensuite la structure : en-têtes, longueurs, décalages, types numériques, encodage des chaînes et des dates, index éventuels. Un agent accélère ce travail répétitif : il compare des dizaines de fichiers, propose une structure et l'écrit sous forme de spécification. REA fournit des outils d'inspection de fichiers et de bases SQLite, et, quand il faut regarder comment l'application lit le format, pilote un décompilateur sur l'exécutable³. Chaque hypothèse de l'agent se vérifie sur un fichier connu, avec la discipline décrite dans lire une sortie REA : un champ inféré d'un motif reste une hypothèse tant qu'un échantillon ne l'a pas confirmé.

Écrivez enfin un parseur, validez-le sur tous les fichiers de référence, puis passez-le sur la production en relevant chaque enregistrement qu'il ne sait pas décoder. Ces rejets sont votre liste d'inconnues : un type de fiche rare, une ancienne version du format, une corruption historique. Ils se traitent un par un, avec les utilisateurs quand le sens d'une valeur échappe à l'analyse.

De la rétro-documentation à la migration

Une fois le format compris, la migration suit la logique d'un changement de base de données : transposer la structure, rendre explicites les règles que l'ancien code faisait respecter sans les déclarer, nettoyer avant de migrer, répéter les migrations à blanc jusqu'à obtenir des rapports de conformité sans écart. C'est la démarche que décrit HFSQL vers PostgreSQL pour les applications WinDev, vers PostgreSQL. La rétro-documentation du format en est l'étape amont.

Pour le reste de l'application, voir le hub legacy, et pour une stack précise, Delphi.

Questions fréquentes

Un format de fichier est-il protégé par le droit d'auteur ?

Pas en tant que forme d'expression du programme selon la CJUE (C-406/10, 2 mai 2012), qui réserve le cas d'un format original protégé comme œuvre. Le code qui lit et écrit ce format peut l'être, et votre contrat de licence peut contenir des clauses à faire examiner par votre juriste.

Peut-on rétro-documenter un format pour migrer ses propres données ?

C'est le cas le plus favorable : vos données, des fichiers en votre possession, un objectif de continuité. Faites tout de même valider le cadre par votre juriste.

Comment valider le parseur ?

Sur des fichiers dont vous connaissez le contenu, produits exprès par l'application d'origine, puis sur la production en traçant chaque rejet.

Un agent peut-il deviner un format seul ?

Il propose des structures plausibles et compare vite. Sans échantillons connus pour trancher, ses propositions restent des hypothèses.

Nos équipes rétro-documentent les formats et migrent les données dans le cadre de la Software Factory, avec un rapport de conformité à chaque migration à blanc.

Sources

1. CJUE, 2 mai 2012, SAS Institute, C-406/10, curia.europa.eu.
2. Directive 2009/24/CE concernant la protection juridique des programmes d'ordinateur, articles 5 et 6, eur-lex.europa.eu ; article L122-6-1 du Code de la propriété intellectuelle, legifrance.gouv.fr.
3. morluto/rea, README, tableau « What you can analyze » (SQLite, packages et ressources, binaires natifs), github.com/morluto/rea, consulté le 18 octobre 2026.