Sur un projet de refonte numérique impliquant une migration de contenus existants, la question du chiffrage arrive toujours tôt (souvent trop tôt). Avant même d'avoir pu regarder ce qu'on est censé migrer. C'est ce décalage-là qu'on a décidé de combler autrement, sur un projet récent, en mettant un peu de code au service de l'estimation.
Le projet impliquait de reprendre un large corpus de documents existants, plusieurs centaines de fichiers PDF, pour les transformer en contenu structuré, destiné à être intégré dans un CMS ou généré sous forme de pages HTML statiques. Ces documents étaient tous au même format en apparence, mais provenaient de sources différentes, avec des structures internes très variées.
La contrainte est connue de tous ceux qui ont déjà travaillé sur ce type de migration : un PDF n'est pas un contenu, c'est une mise en page figée. Extraire les informations utiles, les structurer, les préparer pour une intégration propre dans un CMS c'est un travail qui peut aller du quasi-automatique au très manuel selon la qualité du document source. Et c'est précisément là que le chiffrage devient périlleux.
La question posée était simple en surface : combien de temps faut-il pour extraire, structurer et intégrer ces contenus ? Mais y répondre honnêtement supposait d'abord de comprendre ce qu'on avait réellement entre les mains.
Annoncer un chiffrage global sans cette connaissance, c'est prendre un risque double : sous-estimer les cas complexes, ou sur-facturer les cas simples. Dans les deux cas, la confiance avec le client en prend un coup au moment de l'exécution.
En ouvrant une vingtaine de documents à la main, on confirme rapidement ce qu'on pressentait : derrière l'uniformité apparente du format, il y a en réalité plusieurs familles bien distinctes. Certains documents sont des natifs numériques, propres, bien structurés, faciles à traiter. D'autres sont issus de scans, d'impressions numérisées, ou présentent des mises en page complexes qui rendent l'extraction de texte délicate voire impossible sans étape préalable.
Six familles émergent de cet inventaire manuel. Chacune a ses propres caractéristiques, ses propres marqueurs, son propre niveau de complexité d'extraction. Et dans chaque famille, le temps à passer par document est très différent.
C'est là que l'approche change.
Plutôt que de continuer l'inventaire à la main, ce qui aurait pris des jours pour un résultat approximatif, on a développé un petit script d'analyse automatique du corpus. L'idée n'était pas de produire un outil de production, mais un outil d'exploration : quelque chose qui nous permette de catégoriser rapidement l'ensemble des documents, de mesurer la proportion de chaque famille, et d'identifier les cas problématiques.
Le script fonctionne sur un principe simple : il cherche dans chaque document des indices caractéristiques et des signatures textuelles propres à chaque famille identifiée manuellement. Il lit les sections stratégiques des fichiers (en-têtes, mentions légales, colophons) là où ces marqueurs se trouvent généralement, et attribue chaque document à la famille correspondante.
Ce qui est intéressant dans cette approche, c'est qu'elle force à formaliser ce qu'on sait de manière intuitive. En codant les règles de classification, on les rend explicites, discutables, améliorables.
Le premier passage classe la grande majorité des documents sans difficulté. Les familles les plus fréquentes sont bien représentées, les marqueurs fonctionnent. On obtient déjà une vue d'ensemble fiable sur 80 % du corpus.
Les 20 % restants révèlent des situations inattendues. Certains documents contiennent du texte techniquement présent mais illisible par les outils d'extraction (du texte en miroir, généré par une anomalie de composition par exemple). D'autres n'ont tout simplement aucune couche textuelle : ce sont des images, des scans, sans texte extractible. Ces deux catégories de cas sont isolées et flagguées distinctement, plutôt que d'être absorbées dans un fourre-tout "non identifié" qui fausserait le chiffrage.
On passe les résultats en revue avec un œil critique : les documents présumés appartenir à une famille sans signature formelle sont vérifiés manuellement. Les règles de priorité entre familles sont ajustées là où des ambiguïtés apparaissent. À l'issue de cette passe, le corpus est classifié de manière fiable, documentée, et reproductible.
Une fois le corpus typologisé, le chiffrage devient un exercice structuré. Pour chaque famille, on peut poser des hypothèses précises et les documenter :
Le résultat : un chiffrage par strates, lisible, avec des hypothèses visibles pour chaque ligne. Le client comprend d'où vient chaque estimation. Et si les volumes changent en cours de projet, le modèle se recalibre facilement.
Ce qui est frappant dans cette expérience, c'est la rapidité avec laquelle un peu d'automatisation transforme une zone grise en terrain connu. Quelques heures de développement pour le script, quelques itérations d'affinage et on passe d'un corpus opaque à une cartographie précise.
Mais au-delà du gain de temps, c'est la qualité de la conversation avec le client qui change. Présenter un chiffrage construit sur des données réelles plutôt que sur une intuition, c'est une posture différente. On n'estime plus, on démontre.
C'est une approche qu'on applique désormais systématiquement dès qu'un projet implique une reprise de contenus existants : regarder les données avant de chiffrer, automatiser l'exploration quand le volume le justifie, formaliser les hypothèses pour les rendre discutables. La migration n'est plus une boîte noire, elle devient un plan.
