Un vendredi après-midi, l’équipe opérations reçoit vingt incidents similaires : des commandes dupliquées, un stock qui ne tombe pas juste et plusieurs clients en attente de réponse. Quelqu’un propose « d’installer un agent IA » pour classer les cas, préparer des réponses et ouvrir des tâches dans l’ERP. L’idée paraît raisonnable jusqu’à ce que la vraie question arrive : qui décide ce que l’agent a le droit de faire, et ce qu’il ne doit jamais faire ?
L’IA opérationnelle échoue rarement par manque d’intelligence ; elle échoue quand l’entreprise lui demande de résoudre un processus qu’elle n’a pas elle-même gouverné.
Ma thèse est simple : un agent IA pour les opérations ne mérite la production que s’il réduit les frictions sans introduire d’ambiguïté. Si votre processus est déjà fragile, automatiser la fragilité ne fait qu’accélérer l’erreur.
Le vrai problème n’est pas « utiliser l’IA », c’est déléguer des décisions sans conception
Dans une entreprise de taille moyenne, un agent IA peut être utile pour des tâches précises et répétitives : classer des incidents, extraire des données d’emails, proposer des réponses, détecter des commandes anormales ou préparer des synthèses pour un responsable. Mais cela ne fonctionne que si le processus a des limites claires.
Trois signes que vous n’êtes pas encore prêt :
- Les équipes traitent les incidents différemment selon la personne de service.
- Il n’existe pas de taxonomie stable des motifs, statuts ou priorités.
- Personne ne sait quelles exceptions nécessitent une revue humaine obligatoire.
Si l’agent apprend à partir d’historiques incohérents, il amplifiera cette incohérence. Si les données maîtres de l’ERP sont sales, l’agent ne les corrige pas : il les transforme en réponse convaincante.
Ce qu’un agent utile peut réellement faire en opérations
Un agent bien cadré ne remplace pas une personne. Il réduit le temps entre un événement et la bonne action.
Exemples réalistes :
- Lit un email client, identifie la commande et suggère le type d’incident.
- Consulte l’ERP et le système logistique avant de rédiger une réponse.
- Ouvre une tâche avec le contexte minimal nécessaire pour qu’un opérateur agisse.
- Escalade automatiquement s’il détecte des montants élevés, des retours sensibles ou des erreurs d’inventaire.
L’essentiel est que l’agent ne « décide » pas de tout. Il doit agir comme un assistant avec des droits limités et des sorties vérifiables. En pratique, cela signifie :
- des entrées structurées
- des actions autorisées par type de cas
- des journaux à chaque étape
- une revue humaine aux bons seuils
Si vous ne pouvez pas auditer son cheminement, il n’est pas prêt pour la production.
Un scénario réaliste : moins d’emails, plus de contrôle
Imaginons une entreprise de distribution avec Shopify, un ERP et un support par email. Chaque jour arrivent des incidents sur des commandes incomplètes, des changements d’adresse et des questions sur l’état des expéditions. L’équipe perd du temps en triage parce que l’information est dispersée.
Un agent bien conçu peut faire trois choses utiles :
- Extraire la commande, le client, l’entrepôt et le statut depuis plusieurs systèmes.
- Classer l’incident selon des règles métiers.
- Préparer un brouillon de réponse et créer une tâche interne.
La valeur n’est pas de « répondre comme un humain ». La valeur est de donner à l’opérateur une proposition raisonnable avec un contexte consolidé.
Mais même là, il y a des limites : si l’ERP et la plateforme e-commerce sont en désaccord, l’agent ne doit pas masquer l’écart avec une réponse bien tournée. Il doit le signaler.
Le point inconfortable : automatiser trop tôt aggrave souvent l’opérationnel
La décision controversée est la suivante : parfois, il vaut mieux empêcher l’agent de faire moins de choses que ce qu’il pourrait techniquement faire.
C’est inconfortable parce que les équipes veulent une efficacité visible. Mais en opérations réelles, le coût d’une erreur autonome est souvent supérieur au temps gagné. Un agent capable de rembourser, modifier une commande ou clôturer un ticket sans validation peut transformer un petit problème en incident financier, logistique et service client.
Avant d’automatiser une action, demandez-vous :
- Est-ce réversible ?
- Y a-t-il un impact financier ou réglementaire ?
- Dépend-on d’une exception rare mais critique ?
- Peut-on expliquer après coup pourquoi cela a été fait ?
Si une réponse met mal à l’aise, l’agent doit proposer, pas exécuter.
Les critères pour savoir si vous êtes prêt
Un projet sérieux d’agent opérationnel devrait commencer par un cas étroit et mesurable. Pas par « l’IA pour tout ».
J’utiliserais quatre critères :
- volume répétitif élevé
- risque faible par cas individuel
- données relativement accessibles
- règles métiers stables
Et j’ajouterais trois signaux opérationnels avant la mise en production :
- un taux de revue humaine sous un seuil raisonnable
- une vraie réduction du temps de triage
- aucune ambiguïté sur le responsable de l’action finale
Si l’équipe ne fait pas confiance au résultat, le système n’est pas prêt même si la démonstration est impressionnante.
La bonne question n’est pas de savoir si un agent IA peut faire le travail. C’est de savoir si votre opération est prête à vivre avec un assistant rapide, mais qui doit rester dans des limites. Chez Codefuente, c’est souvent là que nous commençons : définir ce qu’il faut automatiser, surveiller et laisser à l’humain.