Ce qui fait tenir un pipeline documentaire en production

Un système IA qui marche en démonstration et un système IA qui tourne tous les jours ne se ressemblent pas. Et ce n’est pas une question de modèle : le modèle est la partie qu’on remplace le plus facilement.

J’ai conçu et mis en production, dans un contexte industriel exigeant, un pipeline qui traite des centaines de documents scannés par mois. Des feuilles de temps papier, numérisées, qui finissaient auparavant en saisie manuelle avec les erreurs de report que ça implique.

Le trajet d’un document, et ce qu’il ne dit pas

Le trajet tient en trois temps.

Le document arrive dans un dossier réseau et part tout seul en traitement : personne ne clique, personne ne dépose dans une interface, le déclencheur est l’arrivée du fichier. Il est ensuite lu par un moteur d’extraction puis fiabilisé par un modèle avec vision, avec normalisation, score de confiance et rapprochement avec l’annuaire. Il est enfin écrit dans la base métier de façon transactionnelle : tout ou rien, avec retour arrière complet à la moindre erreur.

C’est la partie qu’on met dans un schéma, et c’est celle qui impressionne en réunion. Ce n’est pas elle qui décide que le système sera encore là dans deux ans.

Choix n°1 : rien n’entre en base sans validation humaine

Le document et les données extraites sont présentés côte à côte, quelqu’un valide. Jamais d’import cent pour cent automatique, même quand le score de confiance est excellent.

Ce n’est pas de la prudence excessive, c’est un choix de conception qui produit deux effets. Le premier est l’auditabilité : chaque enregistrement de la base a un responsable identifiable, ce qui est une exigence forte dans un contexte réglementé ou audité. Le second est l’adoption : le métier accepte de confier ses données à un système sur lequel il garde la main. Un système que personne n’ose contredire est un système que personne n’utilise.

La validation coûte du temps, évidemment. C’est le choix n°2 qui la rend décroissante.

Choix n°2 : chaque correction est mémorisée et réinjectée

Quand un opérateur corrige une extraction, la correction ne se perd pas dans un formulaire. Elle est reprise dans les traitements suivants.

Le système s’améliore donc avec l’usage, sans réentraînement, sans nouveau projet et sans facture supplémentaire. C’est le mécanisme qui fait que la charge de validation baisse mois après mois au lieu de rester constante, et c’est ce qui transforme un coût d’exploitation fixe en coût décroissant.

C’est aussi, en pratique, ce qui décide de la rentabilité réelle d’un projet d’automatisation documentaire. Un pipeline dont la charge de relecture ne baisse jamais est un pipeline qui déplace le travail au lieu de le supprimer.

Choix n°3 : les briques d’extraction sont interchangeables

Le moteur qui lit les documents est isolé derrière une interface. Si un meilleur moteur sort l’an prochain, ou si le fournisseur triple ses tarifs, on le remplace sans toucher au reste du système.

C’est une décision d’architecture prise le premier jour, et elle vaut aujourd’hui plus cher que le choix du modèle lui-même. Dans un marché où les moteurs d’extraction changent tous les six mois, un système collé à un fournisseur est un système dont le coût de sortie augmente chaque mois.

Vu du dirigeant, la traduction est simple : quand le marché bouge, vous ne repayez pas le projet.

Aucun de ces trois points n’est un sujet d’IA

Traçabilité, boucle de retour, découplage : ce sont des sujets d’ingénierie logicielle, exactement ceux qu’on applique au reste d’un système d’information sérieux.

C’est précisément pour ça que tant de POC ne passent jamais en production. Ils ont résolu la question la plus visible, la faisabilité, et pas les trois qui décident de la suite. Ce n’est pas un échec des équipes qui les ont construits : ce n’était ni leur mission, ni le moment de s’en occuper.

La question à poser à toute proposition

Quand un diagnostic, un prestataire ou une équipe interne vous dit qu’un cas d’usage est faisable, la vraie question est celle-ci : faisable une fois, ou faisable tous les jours pendant deux ans.

La différence entre les deux réponses ne se voit pas dans une démonstration. Elle se voit dans les trois choix ci-dessus, et il faut les poser avant d’écrire la première ligne de code.