Automatiser avec l’IA : par où commencer ?

Le point de départ

L’intelligence artificielle peut probablement automatiser une partie de vos processus.

La vraie difficulté n’est pas là.

La vraie difficulté, c’est de savoir quelle partie mérite réellement de l’être.

Depuis quelque temps, je vois fleurir des listes de cas d’usage IA dans à peu près tous les métiers comme : 

• Automatiser les comptes rendus.
• Trier les e-mails.
• Répondre aux clients.
• Analyser des documents.
• Préparer des reportings.
• Mettre à jour le CRM.
• Sur le papier, tout devient rapidement automatisable.
• ... et j'en passe.

Et c’est justement là que le problème commence.

Parce qu’un processus n’est pas un bon candidat à l’automatisation simplement parce qu’une IA est techniquement capable d’en exécuter une partie.

Il faut aussi que l’automatisation crée suffisamment de valeur.

Que les données nécessaires soient accessibles.

Que le risque d’erreur soit acceptable.

Que l’on sache mesurer le résultat.

Que la solution puisse s’intégrer au système d’information.

Et surtout qu’une personne soit réellement prête à en prendre la responsabilité dans la durée.

Autrement dit, la question n’est pas seulement :

Qu’est-ce que l’IA peut faire dans mon organisation ?

La question beaucoup plus utile est :

Où l’IA peut-elle améliorer un processus de manière mesurable, maîtrisée et durable ?

C’est cette question que je vous propose d’explorer ici.

Elle me paraît particulièrement importante pour une DSI ou un dirigeant.

À ce niveau, le sujet n’est pas de collectionner des assistants et un amas de prototypes indépendants.

Il est de construire une trajectoire de transformation.

• Quels processus faut-il repenser en priorité ?
• Quelles capacités doivent rester humaines ?
• Quelles données et quelles intégrations faudra-t-il rendre disponibles ?
• Quel niveau de contrôle l’organisation souhaite-t-elle conserver ?
• Et comment passer d’une première expérimentation à un système réellement exploité par les équipes ?

Pas uniquement pour trouver une bonne idée de POC (= Proof Of Concept).

Mais pour éviter de construire une démonstration a effet "Wouaouh" qui ne survivra jamais à son passage dans la vraie vie 😅

Avant de parler d’IA, parlons du processus réel

Il existe souvent deux versions d’un même processus.

La version décrite dans la procédure.

Et la version que les équipes exécutent vraiment.

Dans la première, chaque demande arrive par le bon canal, contient les bonnes informations, suit le bon circuit de validation et laisse une trace parfaitement exploitable.

Dans la seconde, une pièce jointe est manquante, une décision se prend directement dans Teams, un collaborateur modifie son propre tableau Excel et quelqu’un relance Gérard parce que lui seul sait comment traiter les cas inhabituels.

Je caricature à peine 🤣

En somme, automatiser un processus théorique sans comprendre le processus tel qu'il est dans la vraie vie, est l’une des meilleures façons de réussir une démo mais de rater tout ce qui suit.

Je commencerais donc toujours par observer le travail réel.

• Qu’est-ce qui déclenche le processus ?
• Quelles informations sont réellement utilisées ?
• Dans quels outils se trouvent-elles ?
• Quelles décisions sont prises ?
• Sur la base de quelles règles ?
• Où apparaissent les exceptions ?
• Quelles opérations sont des ressaisies ?
• Qu’est-ce qui oblige une personne à interrompre son travail ?
• Et surtout : où se trouve aujourd’hui la valeur du jugement humain ?

Cette observation peut prendre plusieurs formes : entretiens, atelier de cartographie, immersion auprès des utilisateurs, analyse des tickets et études de logs lorsque les systèmes produisent suffisamment de traces.

Le niveau de sophistication de la méthode importe moins que la qualité de l’observation.

Je préfère largement une heure passée à regarder un collaborateur traiter dix vrais dossiers qu’un magnifique diagramme décrivant un processus que plus personne ne suit.

N’automatisez pas un processus. Décomposez-le.

J'ai souvent entendu dire des choses comme : 

« On souhaite automatiser le traitement des demandes clients »
« On aimerait automatiser le recrutement »
« Et si on automatisait le pilotage de projet ? »

C’est beaucoup trop large.

Un processus est généralement composé d’activités de natures très différentes et parfois très complémentaires comme :

• Collecter une information
• Vérifier qu’un dossier est complet
• Extraire des données d’un document
• Appliquer une règle
• Rechercher un contexte
• Produire une synthèse
• Formuler une recommandation
• Prendre une décision
• Exécuter une action dans un outil
• Informer une personne
• Gérer une exception.

Certaines activités relèvent sans doute d’une automatisation classique.

D'autres nécessitent la compréhension de texte, de contexte, d’image ou de langage naturel.

D’autres encore peuvent être assistées par l’IA, mais ne devraient probablement pas lui être déléguées.

Et parfois, la meilleure décision consiste tout simplement à supprimer l’activité.

Avant de me demander comment automatiser une tâche, j’utiliserais donc une séquence très simple :

1. Peut-on la supprimer ?
2. Peut-on la simplifier ?
3. Peut-on la standardiser ?
4. Peut-on l’automatiser avec des règles déterministes ?
5. L’IA apporte-t-elle quelque chose que l’automatisation classique ne sait pas bien faire ?

Mettre une IA sur une étape inutile ne la rend pas utile.

Cela rend simplement l’inutilité plus rapide, plus complexe et souvent plus chère.

Automatisation classique, IA ou agent : ne mélangeons pas tout

Je trouve utile de distinguer trois familles de solutions.

L’automatisation déterministe

• Si une condition est remplie, le système exécute une action définie.
• Un formulaire validé crée une demande.
• Un seuil dépassé déclenche une alerte.
• Une facture conforme suit un circuit précis.

Lorsque les règles sont stables et les données structurées, c’est souvent la meilleure solution.

Elle est généralement moins chère, plus rapide, plus prévisible et plus facile à tester qu’une IA.

L’IA appliquée à une étape

Elle devient intéressante lorsque l’activité contient de l’ambiguïté ou des données non structurées : 

• Comprendre un e-mail.
• Classer une demande formulée librement.
• Extraire les obligations d’un contrat.
• Comparer une documentation à une situation opérationnelle.
• Produire une synthèse adaptée à un destinataire.

L’IA ne pilote pas nécessairement tout le processus.

Elle traite la partie que les règles classiques gèrent mal.

L’agent IA

Un agent reçoit un objectif, choisit plusieurs actions, utilise des outils, observe leurs résultats et adapte la suite de son exécution.

C’est puissant.

C’est aussi plus difficile à prévoir, sécuriser, tester et expliquer.

J’utiliserais donc un agent lorsque le chemin nécessaire pour atteindre l’objectif varie réellement d’un cas à l’autre.

Pas simplement parce que le mot est à la mode.

Beaucoup de besoins présentés comme « agentiques » peuvent être résolus par un workflow très bien conçu, avec une ou deux étapes utilisant un modèle de langage.

Et c’est parfaitement acceptable.

L’objectif n’est pas de construire le système le plus futuriste.

L’objectif est de construire le système le plus simple capable de produire le résultat attendu avec le niveau de maîtrise nécessaire.

Comment identifier un bon processus à automatiser avec l'IA ?

Pour comparer plusieurs opportunités, je construirais une fiche par processus, ou mieux encore par activité, et je noterais chacun des huit critères suivants de 1 à 5.

1. Le volume

Combien de fois cette activité est-elle réalisée ?

Une minute gagnée sur une opération exécutée dix mille fois peut avoir plus de valeur que deux heures gagnées une fois par trimestre.

Mais le volume ne suffit pas car il a aussi tendance à amplifier les erreurs.

2. L’effort humain

Combien de temps l’activité consomme-t-elle réellement ?

Je ne me contenterais pas d’une estimation déclarative.

Je chercherais un échantillon de cas, avec le temps de traitement, le temps d’attente, le nombre de reprises et les interruptions générées.

3. La stabilité et la répétabilité

• Le processus suit-il un schéma identifiable ?
• Les entrées et les sorties sont-elles relativement stables ?

Si le processus change chaque semaine parce que l’organisation n’a pas encore décidé comment travailler, l’automatisation risque surtout de figer trop tôt une pratique immature.

4. L’accessibilité des données

• Les informations nécessaires existent-elles ?
• Sont-elles numérisées ?
• Sont-elles suffisamment fiables ?
• Peut-on y accéder par API, connecteur, requête ou export ?
• Les droits permettent-ils leur utilisation ?

Une IA brillante, privée du bon contexte, reste une IA brillante qui répond à côté.

5. Le caractère mesurable du résultat

Sait-on définir ce qu’est une bonne sortie ?

• Un classement correct.
• Une donnée correctement extraite.
• Une synthèse complète et fidèle.
• Une action effectuée dans le bon outil.
• Un délai réduit.
• Une anomalie effectivement détectée.
• Si personne ne peut dire objectivement si le système a bien travaillé, il sera très difficile de le piloter.

6. La tolérance à l’erreur

Que se passe-t-il lorsque le système se trompe ?

Une proposition de reformulation médiocre peut être corrigée en quelques secondes.

Un paiement erroné, un refus de dossier injustifié ou un message envoyé au mauvais client sont d’une autre nature.

Je regarderais donc la gravité de l’erreur, sa détectabilité et sa réversibilité.

C’est un point essentiel : une activité peut être techniquement automatisable sans être un bon candidat à l’autonomie.

7. La capacité d’intégration

Le système peut-il lire ce dont il a besoin et agir là où le travail se déroule ?

Une solution qui produit un résultat dans une nouvelle interface, puis oblige un collaborateur à le recopier dans trois outils, n’a peut-être pas automatisé grand-chose.

Je regarderais les API, les connecteurs, les mécanismes d’authentification, les événements disponibles, les limitations de débit, les environnements de test et la qualité des journaux.

8. La valeur métier

Que permet réellement cette automatisation ?

• Gagner du temps ?
• Réduire un délai ?
• Augmenter le nombre de dossiers traités ?
• Éviter des erreurs ?
• Améliorer la qualité d’une décision ?
• Réduire un risque ?
• Créer un service qui n’était jusque-là pas économiquement possible ?

C’est le critère qui doit ramener tous les autres à la réalité.

Une matrice ne prend pas la décision à votre place

Je pourrais additionner les notes et produire un magnifique classement sur 100.

Je le ferais probablement mais je ne laisserais pas le classement décider seul.

Certains critères doivent agir comme des filtres.

Si les données ne sont pas légalement ou techniquement accessibles, le processus-candidat à l'automatisation s’arrête là.

Si une erreur peut produire une conséquence grave et reste difficile à détecter, le niveau d’autonomie doit être réduit.

Si personne ne porte le processus, je ne lancerais pas l’industrialisation.

Et si le résultat n’est pas mesurable, je transformerais d’abord le besoin en hypothèse testable.

J’utiliserais donc la matrice pour structurer la discussion, rendre les arbitrages explicites et comparer des opportunités sur une base commune.

Pas pour donner une apparence scientifique à une décision déjà prise.

Comment calculer le ROI d'une automatisation avec l'IA ?

Le calcul le plus courant ressemble à ceci :

Nombre d’opérations × temps gagné × coût horaire

C’est un bon début.

Mais c’est rarement suffisant.

Imaginons une activité qui représente 1 000 heures par an et un coût de 60 euros par heure.

Si l’automatisation permet de réduire le temps de traitement de 50%, la valeur théorique du gain atteindrait 30 000 euros par an.

Très bien.

Sauf que :

• Tout le monde n’utilisera peut-être pas la solution.
• Qu’elle ne fonctionnera peut-être que sur 70 % des cas.
• Que le temps libéré sera fragmenté en petites séquences difficilement réallouables.
• Et qu’une partie sera absorbée par la vérification du résultat.

Je distinguerais donc au minimum quatre notions :

1. Le gain théorique
2. Le taux de couverture des cas
3. Le taux d’adoption réel
4. Le taux de captation, c’est-à-dire la part du temps libéré que l’organisation parvient réellement à transformer en capacité utile, réduction de coût ou création de valeur.

Une formule plus honnête pourrait ressembler donc à ceci :

Valeur temps annuelle = volume × temps économisé × coût × couverture × adoption × captation

Le taux de captation est souvent le grand absent des présentations.

Pourtant, faire gagner cinq minutes par jour à cent personnes ne signifie pas automatiquement que l’entreprise économise l’équivalent d’un poste.

Cela peut créer du confort.

Réduire la charge cognitive.

Accélérer une réponse.

Permettre de traiter plus de demandes.

Tout cela peut être précieux.

Mais appelons correctement la valeur que nous créons.

 

La valeur n’est pas seulement du temps économisé

Je construirais les retours business autour de plusieurs familles de gains.

• La capacité : temps économisé, volume supplémentaire traité, réduction du backlog, diminution des ressaisies.
  
  
• La vitesse : réduction du temps de cycle, réponse plus rapide, décision prise plus tôt, incident détecté avant qu’il ne devienne critique.
  
  
• La qualité : moins d’oublis, meilleure cohérence, meilleure complétude, standardisation du niveau de service.
  
  
• Le risque : réduction des erreurs, traçabilité, détection d’anomalies, contrôle plus systématique.
  
  
• Le revenu ou la satisfaction : meilleur taux de conversion, service plus personnalisé, réduction de l’attrition, amélioration de l’expérience collaborateur ou client.

Certains de ces gains sont directement monétisables.

D’autres doivent être mesurés par un indicateur intermédiaire.

Je préfère un indicateur imparfait mais suivi avant et après le pilote à une promesse de ROI impossible à vérifier.

Et maintenant, parlons des coûts que l’on oublie

Le coût d’un modèle ou d’une licence n’est qu’une partie de l’équation.

Le coût total comprend potentiellement :

• La découverte et la cartographie du processus
• Le nettoyage ou la structuration des données
• Le développement des intégrations
• Les licences des outils d’orchestration et des connecteurs
• La consommation des modèles
• L’hébergement et la gestion des secrets
• Les revues de sécurité, de protection des données et de conformité
• La constitution des jeux de test
• L’accompagnement des utilisateurs
• Le suivi en production
• Le traitement des incidents
• Les évolutions liées aux outils, aux modèles et au processus métier.

Une automatisation peu coûteuse à démontrer peut devenir chère à fiabiliser.

C’est normal.

Dans une démonstration, on travaille sur le chemin heureux.

Dans la réalité, il faut gérer les dossiers incomplets, les droits insuffisants, les formats inattendus, les indisponibilités, les doublons, les ambiguïtés et les changements d’API.

Je présenterais donc toujours trois scénarios : le prudent, le central et l'ambitieux.

Et je rendrais visibles les hypothèses qui font varier le résultat.

Le ROI d’un projet IA n’est pas une vérité découverte dans Excel.

C’est une hypothèse que le pilote doit progressivement transformer en preuve.

Jusqu'où automatiser un processus avec l'IA ?

Entre « l’humain fait tout » et « l’IA fait tout », il existe plusieurs niveaux intéressants à connaître et à exploiter.

• Niveau 1 - L’IA prépare : elle extrait, classe, synthétise ou rédige. L’utilisateur reste responsable de la suite.
  
  
• Niveau 2 - L’IA recommande : elle analyse la situation et propose une décision ou une action, avec les éléments qui la justifient.
  
  
• Niveau 3 - L’IA prépare l’action : elle préremplit un ticket, un message, une mise à jour ou une opération. Un humain vérifie et valide avant exécution.
  
  
• Niveau 4 - L’IA agit dans un cadre défini : elle exécute automatiquement les cas simples, selon des seuils, des droits et des règles précises. Elle transmet les exceptions à un humain.
  
  
• Niveau 5 - L’IA orchestre plusieurs actions : elle choisit et enchaîne des outils pour atteindre un objectif, tout en respectant des limites explicites et en laissant une trace exploitable.

Je ne commencerais presque jamais au niveau 5.

Je commencerais par le niveau le plus bas capable de démontrer une valeur.

Puis j’augmenterais l’autonomie lorsque les résultats, les contrôles et la confiance le justifient.

La validation humaine n’est pas un échec de l’automatisation.

Elle peut être une étape de conception particulièrement intelligente.

 

Ce que je préconise dans l'architecture finale

Peu importe les outils choisis, je chercherais les mêmes briques.

1. Un déclencheur clair

Un événement, une demande, un horaire, un changement d’état ou une action utilisateur.

2. Un contexte maîtrisé

Le système doit savoir quelles sources consulter, avec quels droits, sur quelle période et pour quel objectif.

3. Une orchestration

Elle enchaîne les étapes, gère les conditions, les reprises et les erreurs.

4. Une part déterministe

Les règles certaines doivent rester des règles. Je n’ai pas besoin d’un modèle de langage pour vérifier qu’un montant dépasse un seuil.

5. Une part probabiliste

L’IA intervient là où il faut comprendre, interpréter, rapprocher ou générer. Sa sortie doit être traitée comme une proposition dont la fiabilité se mesure, pas comme une vérité structurelle du système.

6. Des outils d’action limités

Lire un dossier, préparer un ticket et déclencher un paiement sont trois niveaux de risque très différents. Chaque composant ne devrait disposer que des capacités et autorisations strictement nécessaires.

7. Des garde-fous

Seuils de confiance, règles de validation, données interdites, limites de volume, contrôles de cohérence, approbation humaine et possibilité d’arrêt.

8. Une trace

• Quelles données ont été utilisées ?
• Quel modèle et quelle version ?
• Quelle instruction ?
• Quel résultat ?
• Quelle action ?
• Qui l’a validée ?

Sans trace, il n’y a ni diagnostic, ni amélioration, ni responsabilité, ni véritable sécurité.

Cette approche rejoint d’ailleurs les principes du NIST AI Risk Management Framework, qui articule la gestion du risque autour de quatre fonctions : gouverner, cartographier, mesurer et gérer.

Elle répond aussi à un risque très concret des systèmes agentiques : leur donner trop de fonctions, trop de permissions ou trop d’autonomie, c'est créer des failles plus ou moins importantes, exploitables par le tout venant.

D'ailleurs, si cela vous intéresse, l'OWASP (Open Worldwide Application Security Project) met à disposition un rapport plutôt complet sur les types de failles qu'un LLM peut avoir.

C'est en anglais, mais ça vaut un petit coup d'oeil.

Je vous pose le lien ici : OWASP Top 10 for LLM Applications.

Et les outils dans tout ça ?

Il n’existe pas une suite logicielle universelle pour automatiser un processus avec l’IA.

Le bon choix dépend avant tout du SI, du niveau de risque, des volumes, des compétences disponibles et de la durée de vie attendue de la solution.

Je raisonnerais donc par fonction.

Comprendre le processus

Un atelier bien mené, une observation du travail réel et une cartographie exhaustive peuvent suffire pour commencer.

Lorsque les volumes et les traces le justifient, il est même possible de reconstruire les parcours à partir d'observations sur le terrain et de logs applicatifs.

Elles ne remplacent pas la discussion avec les utilisateurs mais elles permettent de la confronter aux faits.

Choisir le socle d’orchestration

Le marché propose plusieurs manières d’enchaîner les traitements, les appels aux modèles, les contrôles et les actions dans le système d’information.

Approche	Vitesse de démarrage	Maîtrise	Scalabilité et évolution	Usage que je privilégierais
Développement spécifique  interne	Moyenne	Très forte	Très forte si l’architecture est bien conçue	Processus stratégique, volumétrie importante, exigences fortes de sécurité ou besoin d’évolution durable
Low-code auto-hébergé comme n8n	Rapide	Bonne	Moyenne à bonne	POC, automatisation d’équipe, première industrialisation encadrée
Plateforme SaaS comme Make ou Zapier	Très rapide	Limitée	Variable	Cas simple, périphérique, peu sensible et rapidement réversible
iPaaS d’entreprise comme Workato, Boomi ou MuleSoft	Moyenne	Moyenne	Variable	Seulement si l'équipe est déjà structurée autour d’une de ces plateformes d’intégration

Comme vous le voyez, j’ai ici un parti pris.

Lorsqu’un processus est stratégique, appelé à monter en charge ou à évoluer pendant plusieurs années, je privilégierais un socle spécifique maîtrisé en interne.

Cela ne signifie pas tout réinventer.

On peut utiliser des modèles externes, des bibliothèques, des API et des composants existants.

Mais l'idéal est que l’entreprise conserve la maîtrise de l’orchestration, des règles, des droits, des tests, des données, des coûts et des mécanismes de reprise.

Une plateforme visuelle peut produire très vite un effet spectaculaire.

Elle peut aussi devenir difficile à faire évoluer lorsque les branches se multiplient, que les volumes augmentent et que la logique métier devient critique.

Je ne choisirais donc pas un outil uniquement sur la vitesse de la démonstration.

Je regarderais sa capacité à être versionné, testé, supervisé, documenté et repris par une autre équipe.

Agir dans les applications

Je privilégierais d’abord les API et les connecteurs officiels.

MCP peut fournir à une IA une manière standardisée de découvrir et d’utiliser certains outils.

Mais MCP ne résout pas automatiquement les questions de qualité des données, d’autorisation, de sécurité ou de responsabilité.

Lorsque l’application ne propose aucune interface exploitable, un agent peut reproduire les opérations humaines, mais avec une fragilité qu’il faut intégrer dès le départ au coût de maintenance.

Observer et évaluer

Il faut pouvoir reconstituer chaque exécution utile : 

• Quelles données ont été consultées ?
• Quelle version du système a été utilisée ?
• Quel résultat a été produit ?
• Quelle action a été proposée ou exécutée ?
• Qui l’a validée ?
• Pour un premier test, un jeu de cas de référence, des logs structurés et une revue humaine peuvent déjà suffire.

À mesure que le système devient critique, l’évaluation, la traçabilité et le suivi des coûts doivent devenir des capacités à part entière de l’architecture.

Un projet IA n’est pas un projet sur un coin de table

C’est probablement l’un des points les plus sous-estimés, que j'ai déjà pu observer dans mes missions.

Un collaborateur motivé peut produire une démonstration en quelques jours.

Il connecte un modèle à deux outils.

Il prépare un scénario bien choisi.

La démonstration fonctionne.

Tout le monde est impressionné.

Puis la personne change de poste.

Une API évolue.

Un secret expire.

Personne ne sait exactement quelles données sont envoyées, pourquoi le système prend telle décision ni comment le remettre en service.

Puis ça part en prod.

L’effet waouh laisse alors place à la dette technique, aux failles de sécurité prévisibles et à une perte de continuité au premier turnover.

Stop !

Un projet IA doit être traité comme un véritable projet.

Avec une responsabilité, des ressources, un budget, une architecture, des arbitrages et une trajectoire d’exploitation.

Il apporte aussi des sujets supplémentaires.

• Le comportement du système n’est pas toujours déterministe.
• Les données peuvent embarquer des biais historiques.
• Le jeu de test peut surreprésenter les cas simples.
• Les utilisateurs peuvent accorder trop de confiance à une réponse bien formulée.
• Le fournisseur d’un modèle peut faire évoluer son service.

Des risques jusqu’alors peu visibles ou mal formalisés apparaissent dans le processus.

Il faut donc mettre les bonnes personnes au bon endroit.

Cela commence par définir les responsabilités minimales de chaque acteur du projet

• Un sponsor qui porte la valeur attendue et assume les arbitrages
• Un propriétaire du processus qui connaît la réalité opérationnelle
• Un responsable produit ou projet qui tient la trajectoire et les priorités
• Des experts métier capables de définir ce qu’est un bon résultat
• Un responsable technique ou architecte qui garantit la cohérence de la solution
• Des compétences en développement, données et intégration
• Une compétence IA capable de concevoir les évaluations et de comprendre les limites du modèle
• La sécurité, la protection des données et le juridique selon le niveau de risque
• Des représentants des utilisateurs pour l’adoption et la conduite du changement
• Un responsable de l’exploitation, du support et de la continuité

Dans une petite entreprise, une même personne peut porter plusieurs rôles.

Mais les responsabilités, elles, ne disparaissent pas.

Je formaliserais également qui peut modifier les règles, changer de modèle, ajouter une source, élargir une permission et autoriser un nouveau niveau d’autonomie.

Sinon, le système évoluera par petites touches invisibles jusqu’au jour où plus personne ne saura réellement ce qui est en production.

 

Comment construire un POC d'automatisation IA vraiment utile ?

Nous savons déjà qu’un modèle peut résumer un texte, classer une demande ou générer un ticket.

Ce n’est pas la question la plus intéressante.

On va plutôt essayer de diriger nos réflexions sur les contours d'un cas d'usage et comprendre si l'IA a réellement une carte à jouer dans le processus.

• La donnée est-elle réellement accessible ?
• Le contexte disponible suffit-il ?
• La qualité reste-t-elle acceptable sur les cas difficiles ?
• Le temps de vérification ne détruit-il pas le gain ?
• Les utilisateurs adoptent-ils la nouvelle façon de travailler ?
• Le coût reste-t-il cohérent lorsque le volume augmente ?
• Les erreurs sont-elles détectables et récupérables ?

Prenons un exemple de cas d'usage plutôt universel (que je connais très bien) : les tickets d'incident adressés à une DSI.

Plus précisément, la possibilité de pouvoir qualifier et prioriser des demandes métier entrantes.

L’IA pourrait alors reformuler le besoin, identifier les informations manquantes, rechercher dans l'outil ITSM des sujets similaires, consulter la documentation en place et préparer des recommandations.

Avant d'en faire un outil robuste et pérenne, une première phase exploratoire et un POC vous permettront de répondre à toutes ces questions.

Je m’arrêterai volontairement là sur cet exemple qui mériterait sans doute un article à part entière.

Passer du POC au produit

Un POC est temporaire.

Mais un process automatisé en production devient quant à lui, une composante importante du fonctionnement de l’entreprise.

Il faut alors définir un propriétaire métier, un responsable technique, une procédure en cas d’incident, une gestion des accès, des tests de non-régression, une documentation et un plan de continuité.

Il faut aussi suivre plusieurs dimensions : 

• La valeur opérationnelle réellement captée
• La qualité et les erreurs importantes
• L’adoption et le temps de vérification humaine
• Le coût et le temps de traitement
• Les échecs d’intégration et les reprises manuelles
• Les incidents, les actions bloquées et les escalades

Je ne vous apprends sans doute rien en vous disant qu'un système peut être : 

• Techniquement fiable mais ignoré des utilisateurs.
• Très apprécié mais économiquement injustifiable.
• Rapide mais dangereux.
• Ou précis sur les cas simples et chaotique sur les cas plus complexes et importants.

D’ailleurs, en Europe, cette dimension ne peut plus être traitée comme un sujet annexe.

Les dispositions de l’AI Act relatives à la maîtrise de l’IA s’appliquent depuis le 2 février 2025. Et depuis le 2 août 2026, les exigences de transparence prévues par l’article 50 s’appliquent également aux systèmes concernés.

Si cela vous intéresse, je vous invite à lire cette page de la Commission Européenne qui dresse un résumé des principes fondamentaux de l'IA Act.

Donc, je ne transformerais pas pour autant chaque POC en projet réglementaire de six mois.

J’adapterais le niveau de gouvernance au risque, mais je qualifierais ce risque dès le départ.

 

La maintenance commence le jour de la mise en production

Une automatisation avec de l’IA peut se dégrader sans tomber complètement en panne.

Le modèle répond toujours.

Le workflow s’exécute.

Le tableau de bord reste vert.

Mais la qualité baisse parce que le processus a changé, qu’une nouvelle catégorie de dossier apparaît, que la documentation s’est dégradée ou qu’une évolution du modèle modifie les réponses.

Je surveillerais donc la dérive du processus, des données, des intégrations, de la qualité, des usages, des coûts et des risques.

Je conserverais aussi un jeu de cas de référence rejoué à chaque modification importante.

Changer de modèle, modifier une instruction, ajouter une source ou élargir une permission n’est pas un simple réglage.

C’est une évolution du système.

Elle doit être versionnée, testée et documentée.

L’amélioration continue ne consiste donc pas uniquement à améliorer le prompt.

Elle porte sur l’ensemble du système.

• Le processus.
• Les données.
• Les instructions.
• Les modèles.
• Les intégrations.
• Les contrôles.
• Et les pratiques humaines.

Ici ce n'est pas bien compliqué.

Un projet autour de l'IA aura beau bénéficier de l'effet de buzz, cultiver des fantasmes et faire penser à de la magie.

Mais un projet autour de l'IA est avant tout un projet IT.

Elle n'échappe donc pas aux bonnes pratiques de l'industrie informatique qui a, pendant ces dernières décennies, contribué à professionnaliser tout un pan du secteur par des méthodes et pratiques qui ont su largement faire leurs preuves.

Plan d'action : 10 étapes pour automatiser un processus avec l'IA

Si une organisation souhaite lancer sa transformation par l’IA sans partir d’une liste d’outils ou d’idées isolées, voici la démarche que je proposerais.

1. Donner un mandat à la transformation

Il faut commencer par nommer un sponsor, définir l’ambition et fixer les premières limites.

• Cherche-t-on de la capacité, de la vitesse, de la qualité, une réduction du risque ou un nouveau service ?
• Quels types de données et de décisions sont exclus au départ ?
• Quel budget et quelles compétences peuvent réellement être mobilisés ?
• Le premier résultat attendu est une note de cadrage courte et assumée.

2. Constituer le noyau de l’équipe

Je réunirais dès le début le métier, le processus, la technique, la donnée, l’intégration et la sécurité.

Pas nécessairement dix personnes à plein temps.

Mais les responsabilités doivent être nommées et les disponibilités réelles.

Le livrable est une gouvernance simple avec un responsable par décision importante.

3. Inventorier le travail réel

Je sélectionnerais quelques domaines représentatifs et j’observerais les activités concrètes.

• Les volumes
• Les délais
• Les ressaisies
• Les recherches d’information
• Les décisions
• Les exceptions
• Les outils utilisés
• Les contournements

L’objectif n’est pas encore de trouver une idée brillante.

Il est de constituer un portefeuille factuel de problèmes et d’opportunités.

4. Décomposer chaque processus

Pour chaque processus, je séparerais les activités de collecte, contrôle, recherche, interprétation, décision, exécution et communication.

Cette décomposition fait apparaître les véritables axes d’intervention comme : 

• Supprimer une activité inutile
• Simplifier un parcours
• Standardiser une règle
• Automatiser une étape déterministe
• Assister une activité cognitive avec l’IA
• Déléguer une action bornée sous contrôle
• Améliorer les données ou les intégrations avant d’automatiser

Tous les problèmes ne nécessitent pas un modèle.

Et tous les processus ne sont pas prêts au même moment.

5. Évaluer et classer les opportunités

Chaque candidat est évalué avec les mêmes critères : 

• Valeur
• Volume
• Effort humain
• Qualité des données
• Faisabilité d’intégration
• Caractère mesurable du résultat
• Gravité, détectabilité et réversibilité des erreurs
• Effort de construction et de maintenance

Certains critères peuvent agir comme des conditions d’arrêt.

Une donnée inutilisable, une responsabilité absente ou une erreur grave impossible à détecter ne doivent pas être compensées par une bonne note moyenne.

6. Construire un portefeuille équilibré

Je ne retiendrais pas uniquement les cas les plus simples.

Je construirais trois horizons : 

1. Des gains rapides pour apprendre et embarquer les équipes
2. Un ou deux processus stratégiques capables de démontrer une transformation réelle
3. Des chantiers de fond sur les données, les API, les droits, la connaissance et la gouvernance

Le résultat est une feuille de route, pas une liste de POC.

7. Choisir une première expérimentation

Le premier cas doit être assez utile pour intéresser l’organisation et assez borné pour être maîtrisé.

Avant de construire, je définirais la situation de référence, le jeu de cas à tester, les métriques, le niveau d’autonomie et les seuils de décision.

Je commencerais en lecture seule ou en mode fantôme chaque fois que c’est possible.

Le système produit un résultat.

Mais il n’agit pas encore sur le processus réel.

8. Décider à partir des preuves

À la fin de l’expérimentation, trois décisions sont possibles.

1. Arrêter parce que la valeur ou la faisabilité ne sont pas démontrées.
2. Itérer parce qu’une incertitude importante subsiste.
3. Industrialiser parce que les résultats, les risques et les conditions d’exploitation sont suffisamment maîtrisés.

Et arrêter un POC peut être une bonne décision, à condition d’avoir appris quelque chose d’utile.

9. Industrialiser comme un produit

L’industrialisation comprend l’architecture cible, les tests, les droits, la documentation, la formation, le support, la continuité et le suivi des coûts.

Elle prévoit aussi les conditions de retour au processus manuel en cas de problème.

L’objectif n’est pas simplement de mettre le système en production.

Il est de permettre à l’organisation de le comprendre, de l’exploiter et de le faire évoluer.

10. Installer la boucle d’amélioration continue

Les résultats réels alimentent un backlog d’amélioration.

Les erreurs importantes enrichissent le jeu de test.

Les retours des utilisateurs font évoluer le processus et l’interface.

Les coûts, les risques et la valeur sont revus régulièrement.

Le niveau d’autonomie peut augmenter lorsque les preuves le justifient.

Ou diminuer si la situation change.

À l’issue de ce premier cycle, l’organisation doit disposer de quelque chose de beaucoup plus utile qu’une démonstration.

• Un portefeuille de cas d’usage qualifiés.
• Une feuille de route.
• Une équipe et des responsabilités identifiées.
• Des principes d’architecture et de gouvernance.
• Une première expérimentation mesurable.
• Et une méthode pour décider de la suite.

C’est à ce moment-là que l’IA commence réellement à s'installer dans votre environnement.

Finalement, par où commencer ?

Si je devais résumer tout cet article en une seule idée, je commencerais par le travail réel.

Pas par le modèle le plus récent.

Pas par l’outil qui promet de tout automatiser.

Pas non plus par une liste générique de cas d’usage.

Je choisirais un processus suffisamment important pour créer de la valeur, suffisamment observable pour être compris et suffisamment maîtrisable pour expérimenter sans mettre l’organisation en risque.

Puis j’irais vite.

Avec quelque chose de simple.

Le monde des startups nous a appris l’intérêt du MVP (Minimum Viable Product). La plus petite version d’un produit capable de tester une hypothèse de valeur dans des conditions réelles.

Il ne s’agit donc pas de reproduire immédiatement l’ensemble du processus, de connecter toutes les données ou d’automatiser chaque exception.

On peut commencer par une activité.

Un groupe restreint d’utilisateurs.

Quelques sources bien maîtrisées.

Un niveau d’autonomie limité.

Et une validation humaine avant chaque action importante.

Mais attention.

Rapide ne veut pas dire improvisé.

Simple ne veut pas dire fragile.

Et MVP ne veut pas dire démonstration jetable.

Même réduit à l’essentiel, le premier système doit avoir un responsable, des critères de réussite, des accès maîtrisés, des résultats traçables et une manière claire de revenir au fonctionnement précédent en cas de problème.

C’est justement parce que l’objectif est de rester simple que les choix doivent être précis.

Une fois la valeur démontrée, le périmètre peut s’élargir.

Davantage de cas.

Davantage de données.

Davantage d’intégrations.

Et éventuellement davantage d’autonomie.

Le premier projet n’a donc pas besoin d’être spectaculaire.

Il doit être utile.

Rapide à confronter au réel.

Simple à comprendre.

Mesurable.

Et suffisamment bien conçu pour préparer le suivant.

C’est ainsi que l’IA cesse d’être une expérimentation isolée pour devenir progressivement une véritable capacité de transformation de l’entreprise.