Ce que l'IA fait, ce qu'elle propose, ce qu'elle ne décide pas

Le discours ambiant sur l'IA oscille entre le miracle et la menace. Ni l'un ni l'autre n'aide un chef d'entreprise à décider s'il doit automatiser le traitement de ses factures fournisseurs.

Cette page dit ce qu'un dispositif automatisé fait réellement, ce qu'un modèle propose, ce qui doit rester une décision humaine, et comment nous nous engageons à organiser ce contrôle. Elle est volontairement technique : c'est le sujet sur lequel un prestataire sérieux doit pouvoir être interrogé.

Une automatisation classique suit un chemin défini à l'avance. Elle est déterministe : à entrée identique, sortie identique. Elle ne se trompe pas au sens où un humain se trompe — elle applique exactement la règle qu'on lui a donnée, y compris quand cette règle est mauvaise.

C'est pourquoi le travail d'écriture précède la configuration. Une automatisation fige un processus : si le processus n'est pas clair, l'automatisation reproduira l'ambiguïté à grande vitesse.

Un modèle de langage ne suit pas une règle : il produit la suite la plus plausible au regard de ce qu'on lui a donné. C'est ce qui le rend utile sur des tâches que l'on ne sait pas décrire par des règles — comprendre une demande formulée librement, classer un document atypique, résumer un long échange.

C'est aussi ce qui le rend faillible. Un modèle peut produire une réponse fausse avec la même assurance qu'une réponse juste : il n'a pas de mécanisme interne pour signaler qu'il se trompe. Un prestataire qui vous annonce un taux d'erreur nul vous vend une impossibilité technique.

Nous nous engageons à traiter ce point comme une caractéristique du dispositif, pas comme un détail à ne pas mentionner : chaque proposition écrite indiquera où un modèle intervient, ce qu'il produit, et quel est le contrôle prévu sur sa sortie.

Sur les tâches d'extraction et de classification, un dispositif bien construit ne rend pas seulement un résultat : il rend aussi une indication de fiabilité, champ par champ. Un numéro de facture lu sur un document net donne un indice élevé ; le même numéro sur une photo floue donne un indice faible.

Cet indice sert à trancher automatiquement : au-dessus du seuil, le traitement continue ; en dessous, le cas part dans une file de vérification humaine. Le seuil n'est pas une valeur universelle — il dépend du coût d'une erreur dans votre contexte. Une erreur de classement dans une GED se corrige ; une erreur de montant en comptabilité se propage.

Nous nous engageons à fixer ce seuil avec vous, sur un échantillon de vos documents réels, et à mesurer ce que donne l'extraction avant de nous engager sur un périmètre. Aucun taux ne sera annoncé avant cette mesure : il n'aurait aucune valeur.

La question n'est pas de savoir si un humain doit intervenir, mais où. Placer une validation partout revient à ne rien automatiser ; n'en placer nulle part revient à découvrir les erreurs chez le client.

Notre règle de conception place systématiquement une validation aux endroits suivants, et nous nous engageons à ne pas la retirer sans une décision explicite de votre part, tracée.

Nous mettons les dispositifs en service en deux temps. Dans le premier, le système propose et une personne valide chaque cas. Cette phase n'est pas une précaution symbolique : elle produit la mesure qui manque au démarrage, en comparant ce que le dispositif aurait fait à ce qu'un humain fait effectivement.

Dans le second temps, et seulement si la comparaison est concluante, la validation est allégée sur les cas simples — jamais sur les cas listés ci-dessus. Ce passage fait l'objet d'une décision explicite, pas d'un glissement progressif.

Nous nous engageons à ce que la durée de cette première phase soit définie au cadrage, et à ce qu'elle puisse être prolongée sans surcoût si la fiabilité observée ne justifie pas encore l'allègement.

La supervision ne peut pas reposer sur le prestataire seul : il n'est pas là tous les jours, et c'est votre équipe qui verra la première qu'une réponse sonne faux. Elle ne peut pas non plus reposer sur une bonne volonté générale, qui se dilue en trois semaines.

Nous nous engageons à ce que chaque dispositif désigne une personne référente chez vous, formée à lire le journal et à traiter la file de vérification, et à ce que la charge que cela représente soit annoncée honnêtement au cadrage — quelques minutes par jour pour un dispositif courant, pas un poste à créer.

La fréquence de relecture des sorties se fixe avec vous selon l'enjeu : quotidienne sur un assistant en contact avec des clients, hebdomadaire ou mensuelle sur un traitement documentaire interne. Nous ne l'imposons pas d'en haut, et nous refusons de la laisser implicite.

Elle passera. C'est le postulat de départ, et un dispositif conçu sans cette hypothèse est un dispositif fragile.

Nous nous engageons à livrer, avec chaque automatisation, une procédure d'arrêt immédiat, un point de reprise manuelle documenté et testé avant la mise en service, et un canal d'alerte désigné. Le journal d'exécution permet ensuite d'identifier les cas traités pendant la période concernée, plutôt que de devoir tout reprendre par précaution.

Nous nous engageons également à corriger le paramétrage à partir des erreurs constatées, et à ne pas masquer une correction dans une mise à jour silencieuse : ce qui a changé, et pourquoi, vous est indiqué.

Il existe des demandes auxquelles nous répondons non, et il vaut mieux le savoir avant de nous consulter qu'au milieu d'un projet.

Un dispositif automatisé agit sous votre responsabilité d'exploitant, pas sous celle de l'outil ni sous la nôtre. Ce n'est pas une clause de dégagement : c'est précisément ce qui justifie les points de validation, la journalisation et la procédure d'arrêt décrits sur cette page.

Nous nous engageons de notre côté sur la conception, la documentation, la formation de la personne référente et la correction des défauts constatés. Ce partage est écrit dans le contrat de mandat, avant la mise en service, et non découvert au premier incident.