Aujourd’hui, on me demande régulièrement : « Est-ce qu’on pourrait mettre de l’IA là-dessus ? »
Ma réponse commence rarement par l’IA. Je demande d’abord ce qui ne fonctionne pas aujourd’hui : où l’on perd du temps, où les erreurs apparaissent, quelles informations sont difficiles à traiter, et surtout si le problème suit déjà des règles suffisamment claires.
Parce qu’un agent IA pour déplacer une donnée d’un logiciel vers un autre, c’est un peu comme prendre une Formule 1 pour aller chercher du pain à 800 mètres. Ça fonctionne. Mais ce n’est probablement pas l’outil le plus adapté.
L’adoption de l’IA progresse rapidement : en 2025, 20 % des entreprises de l’Union européenne de 10 salariés ou plus utilisaient au moins une technologie d’intelligence artificielle, contre 13,5 % en 2024.
Plus l’IA devient accessible, plus la vraie question me paraît donc être celle-ci : où apporte-t-elle réellement quelque chose ?
Commencer par le problème, pas par la technologie
Prenons une situation très simple. Un dossier passe au statut « validé ». À ce moment-là, une information doit être envoyée dans un autre logiciel et une tâche doit être créée.
Le chemin est connu :
statut validé → envoyer la donnée → créer la tâche.
Il n’y a rien à comprendre ni à interpréter. Dans ce cas, une automatisation classique sera généralement plus simple, plus prévisible et plus facile à maintenir qu’une brique d’IA.
Maintenant, changeons de contexte. Vous recevez chaque jour des demandes rédigées librement. Certaines concernent un rendez-vous, d’autres une facture, un besoin commercial ou un problème technique. Cette fois, il ne suffit plus de transporter une donnée : il faut comprendre ce que la personne veut dire, repérer les informations utiles et décider vers quel traitement orienter la demande.Là, l’IA peut devenir pertinente.
Une tâche répétitive n’a donc pas automatiquement besoin d’intelligence artificielle.
Automatisation, IA, agent : trois niveaux différents
Pour expliquer le sujet simplement, je distingue trois niveaux.
Automatisation, IA, agent : trois niveaux différents
Un formulaire est envoyé, un contact est créé, une notification part et une tâche apparaît dans le bon outil. Le système suit un chemin prévu à l’avance. Il ne choisit pas librement ce qu’il doit faire.
C’est exactement ce qu’on lui demande lorsque la règle métier est claire.
L’IA dans un workflow : une étape demande de comprendre
On peut ajouter une brique d’IA uniquement à l’endroit où l’information devient difficile à traiter avec des règles fixes.
Par exemple : un email arrive, l’IA en comprend le sujet et le classe, puis le workflow classique reprend la main pour exécuter la suite.
L’IA sert ici à interpréter. Elle n’a pas besoin de gérer tout le processus.
L’agent IA : le chemin peut s’adapter
Un agent va plus loin : il reçoit un objectif, peut utiliser plusieurs outils et décider d’une partie des étapes nécessaires pour l’atteindre.Anthropic fait précisément cette distinction entre les workflows, orchestrés selon des chemins prédéfinis, et les agents, qui dirigent plus dynamiquement leur processus et l’utilisation des outils. Leur recommandation est de commencer par la solution la plus simple et de n’augmenter la complexité que lorsque cela se justifie réellement.
Source : Anthropic — Building effective agents
C’est aussi ma manière de travailler.
Les agents IA : utiles, mais pas partout
Je ne suis pas contre les agents IA. Ils peuvent être extrêmement intéressants lorsque le système doit rechercher plusieurs informations, choisir entre différents outils, gérer des exceptions ou adapter son chemin en fonction de ce qu’il découvre.
Mais cela ne signifie pas qu’il faut transformer chaque automatisation en agent.
Imaginez un circuit automobile. Faire la course à vélo serait absurde : le vélo fonctionne, mais il n’est pas adapté au problème. À l’inverse, prendre une Formule 1 pour aller chercher du pain serait tout aussi disproportionné.
Le meilleur outil n’est pas le plus puissant. C’est celui qui est dimensionné pour le problème.
Je regarderais sérieusement la piste d’un agent si le système doit poursuivre un objectif dont les étapes varient, consulter plusieurs sources avant d’agir ou choisir lui-même le prochain outil à utiliser. Je ne le ferais pas pour envoyer une notification, créer un document à partir d’un modèle, contrôler une échéance ou transférer une donnée selon une règle connue.Dans ces derniers cas, on ajoute surtout de la complexité.
Plus d’autonomie signifie aussi plus de contrôle
Plus un système peut décider et agir seul, plus il faut réfléchir à ses limites : que peut-il modifier ? Qui valide ? Que se passe-t-il en cas d’erreur ? Peut-on comprendre ce qu’il a fait et revenir en arrière ?
Le NIST recommande notamment de définir clairement les rôles humains dans la supervision des systèmes d’IA, et d’adapter ce niveau de supervision au contexte et au risque.
Source : NIST AI Risk Management Framework
L’OCDE insiste de son côté sur la traçabilité, la responsabilité et la gestion des risques tout au long du cycle de vie des systèmes d’IA.
Autrement dit, mettre un humain dans la boucle n’est pas un échec de l’automatisation. Sur certains sujets, c’est précisément ce qui rend le système fiable.
Avant d’automatiser, je cherche d’abord ce qu’on peut supprimer
C’est probablement le point sur lequel j’insiste le plus dans mes projets.
Quand une entreprise me montre une tâche répétitive, je ne commence pas par demander comment l’automatiser. Je demande pourquoi cette étape existe encore.
Si votre premier symptôme est surtout le temps perdu dans des opérations répétitives, la page Mes équipes perdent trop de temps sur des tâches répétitives permet de repartir du problème avant de parler de solution.
Un processus peut avoir grandi au fil des années, accumuler des validations, des doubles saisies ou des contrôles devenus inutiles. Si l’on automatise tout sans remettre le fonctionnement à plat, on accélère parfois simplement un mauvais processus.Ma logique est donc plutôt :
Supprimer → simplifier → automatiser → ajouter de l’IA si elle apporte quelque chose → envisager un agent si le niveau d’autonomie le justifie.
C’est la logique que nous appliquons dans l’audit et l’optimisation des processus puis, lorsque cela se justifie, dans l’automatisation des processus.
Trois cas concrets pour voir la différence
1. Des données structurées : l’IA n’a rien à deviner
Sur un projet de gestion d’adhésions et de paiements, plusieurs plateformes devaient être rapprochées. À première vue, le sujet pourrait presque être vendu comme du « rapprochement intelligent ».
Sauf que les données possédaient déjà des identifiants fiables : paiement, abonnement, facture, transaction, formulaire d’origine.
Dans ce contexte, je préfère une règle déterministe :
identifiant exact → rapprochement → contrôle → traitement.
Si un cas ne rentre pas dans les règles, il passe en anomalie et une personne le vérifie. Je préfère cela à une IA qui déciderait que deux transactions « semblent » correspondre.
C’est un bon exemple d’une idée importante : la bonne alternative à l’IA n’est pas toujours davantage d’automatisation.
Parfois, automatiser les cas sûrs et garder quelques cas ambigus pour un humain est la meilleure architecture.
2. Des données semi-structurées : l’IA uniquement là où ça bloque
Sur un autre projet, l’objectif était de récupérer automatiquement des recettes provenant de sources très différentes.
Certaines pages web fournissent déjà des données bien structurées : ingrédients, quantités, temps, étapes. Dans ce cas, demander à une IA de redécouvrir que « 250 g de farine » signifie « 250 g de farine » n’apporte rien.
Mais une recette issue d’une description de réseau social, d’une transcription vidéo ou d’un texte libre pose un autre problème. Les ingrédients se mélangent aux explications, les quantités apparaissent à différents endroits, les étapes ne sont pas toujours clairement séparées.L’architecture devient alors beaucoup plus logique : récupérer d’abord ce qui est structuré, utiliser l’IA uniquement pour comprendre ce qui reste flou, puis revenir à une automatisation classique avec des données propres.
L’IA n’est pas le système. Elle est une brique placée exactement là où la règle cesse d’être fiable.
3. Du langage humain : l’IA peut réellement faire la différence
Prenons maintenant des demandes de logement publiées librement sur les réseaux sociaux.« Je cherche un appartement pour août », « Nous venons à quatre cet été, quelqu’un connaît une location ? » ou « Auriez-vous quelque chose de disponible près de… ? » expriment à peu près la même intention, avec des formulations très différentes.Construire uniquement des règles par mots-clés obligerait à anticiper une multitude de formulations.
Ici, l’IA peut répondre à une question très précise : ce texte correspond-il à une recherche de logement et, si oui, quelles informations peut-on en extraire — lieu, dates, nombre de personnes, budget ?
Puis son rôle s’arrête. Une fois ces données structurées, la suite redevient déterministe : disponibilité, filtres, critères, correspondances.
C’est une architecture que j’aime beaucoup :
langage humain → IA pour comprendre → données structurées → automatisation pour exécuter.
Deux rappels qui évitent de sur-utiliser l’IA
Un moteur de matching n’a pas forcément besoin d’intelligence artificielle. Si les critères sont connus - disponibilité, distance, budget, capacité, préférences pondérées - un système de filtres, de scores et de classement peut être parfaitement suffisant. L’IA devient utile lorsque la demande devient subjective : « je veux quelque chose de calme, mais pas isolé », par exemple.
De la même manière, il n’est pas nécessaire d’atteindre 100 % d’automatisation. Sur un paiement, un contrat ou un historique client, il est parfois plus rationnel de traiter automatiquement tous les cas sûrs et de faire contrôler les quelques anomalies restantes.
Une grille simple pour choisir
| Besoin | Question | Approche à regarder en premier |
|---|---|---|
| Transporter | Faut-il déplacer une donnée d’un outil à un autre ? | Automatisation |
| Calculer | Les règles et formules sont-elles connues ? | Règles / automatisation |
| Comprendre | Faut-il interpréter du texte, une image ou une donnée variable ? | IA ciblée |
| Décider | La décision peut-elle être cadrée ou nécessite-t-elle du jugement ? | Règles, IA assistée ou humain |
| Exécuter | Le chemin est-il fixe ou doit-il s’adapter ? | Workflow ou agent |
Cette grille évite une erreur que je vois souvent : confier tout le processus au même outil simplement parce qu’il sait techniquement le faire.
Un exemple sans IA : plusieurs heures ramenées à quelques minutes
Dans une activité digitale, une base de 100 à 200 éléments devait être mise à jour toutes les deux semaines. La tâche prenait plusieurs heures, mais les règles étaient connues, les données identifiables et rien ne nécessitait d’interprétation.
Nous avons automatisé l’essentiel de la préparation tout en conservant quelques contrôles humains.
Plusieurs heures de travail ont été ramenées à quelques minutes. Sans IA. Sans agent.
Parce qu’il n’y en avait tout simplement pas besoin.
Vous pouvez retrouver cette logique dans l’étude de cas consacrée à l’automatisation de tâches récurrentes.
Les 7 questions que je pose avant de choisir
Les 7 questions que je pose avant de choisir :
- Quelle tâche cherchez-vous réellement à améliorer ? Où perdez-vous du temps ou créez-vous des erreurs ?
- Cette tâche est-elle toujours nécessaire ? Peut-on la supprimer ?
- Suit-elle des règles stables ? Si oui, une automatisation classique peut suffire.
- Faut-il comprendre ou interpréter une information ? Du texte libre, une image ou une donnée difficile à structurer peuvent justifier l’IA.
- Le chemin est-il toujours le même ? S’il doit s’adapter en cours de route, la piste agent devient plus pertinente.
- Quel est le risque si le système se trompe ? Plus l’impact est fort, plus le contrôle doit l’être aussi.
- Le gain justifie-t-il la complexité ajoutée ? Une solution doit aussi être testée, documentée, surveillée et maintenue.
Ce que je retiens de tous ces cas
Mon travail n’est pas de chercher où mettre de l’IA.
C’est souvent exactement l’inverse : déterminer où elle apporte réellement quelque chose et l’enlever partout ailleurs.
Dans la réalité, les solutions les plus pertinentes sont souvent hybrides. Une partie du processus reste déterministe, une petite partie bénéficie de l’IA, et l’humain garde la main là où son jugement apporte de la valeur ou protège l’entreprise d’une erreur coûteuse.
Le sujet n’est pas d’avoir le système le plus sophistiqué.
Le sujet est d’avoir celui qui résout correctement votre problème.
Vous ne savez pas encore quelle approche choisir ?
Montrez-moi comment vous travaillez aujourd’hui.
Je regarderai d’abord ce qui peut être supprimé ou simplifié, puis ce qui mérite réellement d’être automatisé — avec ou sans IA.
