« On vient chercher de l'IA, et on découvre qu'on a d'abord un sujet de transformation numérique et d'automatisation. » Je l'entends chez des industriels, et le constat vaut aussi pour les collectivités et les établissements médico-sociaux.
L'IA ne règle pas seule un processus mal câblé. Elle le rend plus rapide, défauts compris. Il faut d'abord comprendre comment l'information circule, supprimer les ressaisies, automatiser ce qui est répétitif, et seulement ensuite placer l'IA là où il reste une décision à prendre sur du texte.
L'ordre compte. Chaque temps prépare le suivant, et beaucoup de gains arrivent avant même la première ligne d'IA.
Je prends un dossier réel et je le suis de bout en bout, avec les personnes qui le traitent. On note chaque ressaisie, chaque attente et chaque aller-retour, logiciel par logiciel. C'est l'audit lean : il montre où part le temps, sans encore rien acheter.
Ce qui est répétitif et prévisible se règle sans IA : flux entre logiciels, imports et exports planifiés, connecteurs, règles simples. C'est moins spectaculaire, mais c'est là que disparaissent les ressaisies.
L'IA arrive là où il reste un jugement à porter sur du texte : trier des demandes, extraire les informations d'un document, résumer un dossier, rédiger un compte rendu. Elle s'appuie alors sur des données propres et un processus qui tient.
Le signe le plus fiable, c'est la ressaisie. Des agents copient-collent encore entre logiciels en 2026, et des administratifs saisissent le même dossier dans trois outils qui ne se parlent pas.
Chaque ressaisie coûte du temps et ajoute un risque d'erreur, et personne n'a de vue d'ensemble sur le dossier.
La cause est rarement la mauvaise volonté des équipes. Elle tient souvent aux logiciels métiers eux-mêmes, en particulier en RH et en finance, quand ils verrouillent leur marché et n'exposent aucune API. Les données y entrent, mais elles en sortent mal.
Un modèle de langage sait lire, résumer, classer et rédiger. Il ne répare pas un flux de données qui n'existe pas. Posé sur un processus où l'information est ressaisie trois fois, il produit un quatrième exemplaire, plus vite, avec ses propres erreurs en prime.
C'est un piège courant : acheter un outil d'IA en espérant qu'il fasse disparaître un problème d'organisation. On paie une licence, la démonstration impressionne, et quelques mois plus tard les équipes ont repris leurs habitudes parce que l'outil ne s'insère nulle part dans leur travail réel.
Former les équipes est utile, et je le fais moi-même en conférence. Une formation montre ce qui est possible, mais changer le processus demande un autre travail. Un dirigeant me l'a dit simplement : « La formation, c'est bien, maintenant il faut le faire pour de vrai, dans les projets. »
La question qui compte arrive quelques mois plus tard : qui utilise l'IA chaque semaine, sur quelle tâche, et qu'est-ce que ça a changé ? Si personne ne sait répondre, c'est que l'outil n'a pas trouvé sa place dans un processus réel.
C'est un cas fréquent dans le secteur public et dans le médico-social, et il a des solutions. Selon ce que le contrat et l'éditeur permettent, je passe par des exports planifiés, par une lecture directe de la base de données, ou en dernier recours par l'automatisation de l'interface, qui reproduit les clics d'un utilisateur. Cette dernière solution reste fragile, je la réserve aux cas où rien d'autre n'est possible.
Le levier durable se trouve dans les contrats. Au prochain renouvellement ou au prochain appel d'offres, exigez une API documentée et une clause de réversibilité des données. Sinon, chaque ressaisie supprimée aujourd'hui restera dépendante du bon vouloir de l'éditeur.
Avec des données de santé, la prudence s'impose : on minimise ce qui circule, on garde la trace de chaque accès, et l'hébergement doit être certifié HDS.
Je mesure peu de choses, mais je les mesure avant et après : le nombre de ressaisies par dossier, le délai de traitement de bout en bout et la part de l'équipe qui utilise l'outil chaque semaine. Si ces trois indicateurs ne bougent pas, le projet n'a rien changé, même si la démonstration était réussie.
Par la cartographie, puis l'automatisation. L'IA vient en dernier, sur les tâches où il reste une décision à prendre sur du texte. Commencer par l'IA revient souvent à accélérer un processus qui ressaisit déjà trois fois la même information.
C'est le relevé de la façon dont un dossier circule réellement dans l'entreprise : qui le traite, dans quels logiciels, avec quelles ressaisies et quelles attentes. On la mène processus par processus, en commençant par celui qui génère le plus de ressaisies, avec les personnes qui le font tourner au quotidien.
Une formation montre ce qui est possible, mais changer le processus demande un autre travail. Tant que l'IA ne s'insère pas dans une tâche réelle, avec des données accessibles, les équipes reviennent à leurs habitudes. Il faut ensuite déployer un ou deux usages concrets dans les projets et mesurer leur usage réel.
Avec des exports planifiés, une lecture de la base de données quand le contrat le permet, ou en dernier recours l'automatisation de l'interface. À plus long terme, il faut exiger une API et une clause de réversibilité au prochain renouvellement du contrat de l'éditeur.
Pas forcément. Une équipe interne peut le faire si elle prend le temps de suivre un dossier de bout en bout sans juger personne. Un regard extérieur aide quand les logiciels sont nombreux, quand les services se renvoient la responsabilité ou quand il faut arbitrer entre automatisation, IA et changement d'outil.
On part d'un processus qui vous coûte des ressaisies, et on regarde ensemble ce qui relève de l'automatisation et ce qui relève de l'IA.
