en
Pendant vingt ans, automatiser un processus métier a buté sur le même obstacle : une partie du travail dépendait d’informations enfermées dans des documents qu’aucun système ne savait lire seul. On contournait le problème avec de la main-d’œuvre : saisie, ressaisie, contrôles manuels, exceptions traitées au cas par cas. Le document n’était pas le sujet ; il était le point de friction qui empêchait le processus de tourner sans intervention humaine.
Ce verrou vient de sauter. Mais la vraie rupture n’est pas que les modèles savent désormais lire un document : c’est qu’on peut confier à des agents la responsabilité d’enchaîner les actions métier qui en découlent, du déclencheur jusqu’à l’opération exécutée dans le système d’information. Le sujet de cet article n’est donc pas la compréhension documentaire. C’est l’orchestration : comment un événement entrant met en mouvement une chaîne d’actions décidée et exécutée par des agents, et ce que cela change dans la façon de concevoir l’automatisation des processus.
Extraire proprement un champ ne crée aucune valeur tant que rien ne se déclenche derrière. C’est le point que la plupart des discours sur l’IA documentaire ratent : ils s’arrêtent à la donnée structurée, comme si une instance JSON validée était un résultat. Ce n’en est pas un. Une donnée qui dort dans une table est aussi inerte qu’un PDF non lu. La valeur naît quand un système décide quoi en faire, et le fait.
Or l’enchaînement des actions est précisément ce que les approches classiques savaient le moins faire. On câblait un pipeline : extraire, puis rapprocher, puis valider, puis notifier. Ça tient tant que le processus est linéaire et stable. Dès que les cas se diversifient, un fournisseur qui facture autrement, un dossier auquel il manque une pièce, une exception réglementaire, le pipeline figé devient un buisson de conditions ingérables. La logique métier est encodée une fois pour toutes dans le code, et chaque nouveau cas réel exige une rallonge. Le coût ne disparaît pas : il se déplace de la saisie manuelle vers la maintenance d’un arbre de décisions qui grossit sans fin.
Un agent n’exécute pas une séquence pré-écrite. On lui confie un objectif de haut niveau, traite ce dossier client, et on lui donne accès à des outils : base de données, API métier, déclencheurs de workflow, autres agents. C’est lui qui décide de la séquence, appelle les bons outils, réagit aux résultats intermédiaires et ajuste sa trajectoire.
La différence avec le pipeline est structurelle. Le pipeline porte la logique dans son code ; le système d’agents la porte dans l’objectif et les outils disponibles, et laisse le raisonnement au moment de l’exécution. C’est ce déplacement qui rend l’automatisation tenable face à la variété des cas réels : on ne code plus chaque chemin, on décrit un but et on outille un agent pour l’atteindre. On gagne en flexibilité ; on paie en difficulté d’observation et de gouvernance, et c’est cet arbitrage, plus que la performance d’extraction, qui décide de la viabilité d’un déploiement.
L’architecture qui se stabilise n’est pas un agent unique et omniscient, mais un ensemble d’agents spécialisés qui se coordonnent. Chacun maîtrise un domaine étroit et expose une interface claire au reste du système.
Au-dessus, un agent orchestrateur répartit le travail, gère les dépendances entre étapes et arbitre les conflits. Cette décomposition n’est pas qu’une élégance d’architecte : elle rend chaque agent testable isolément, remplaçable et auditable. Quand une action part de travers, on sait quel agent l’a décidée et sur quelles données. La prise de décision distribuée n’est exploitable que si elle reste traçable de bout en bout.
Trois exemples montrent ce que l’orchestration multi-agents change concrètement. Dans chacun, le document n’est qu’un déclencheur ; l’intérêt est ailleurs, dans la séquence d’actions qui s’enchaîne sans intervention.
L’extraction lit la facture, l’agent de contexte récupère le bon de commande correspondant, l’agent de décision détecte les écarts (prix, quantité, TVA) et statue, l’agent d’action passe la facture en paiement ou ouvre un ticket d’escalade avec un commentaire explicatif. Le comptable ne traite plus que les exceptions remontées par la chaîne.
Un dossier arrive avec un contrat, une pièce d’identité, un justificatif et un courrier. L’orchestrateur lance les extractions en parallèle, fait vérifier la cohérence entre les pièces, déclenche les vérifications de conformité, puis ouvre le dossier dans l’outil métier en y attachant la synthèse. Un seul objectif en entrée, une chaîne d’étapes hétérogènes en sortie.
La transcription devient une liste de décisions avec assignés, deadlines et priorités. L’agent d’action crée directement les tâches dans Jira, Asana ou le CRM, et notifie les responsables. La valeur n’est pas le résumé, c’est le travail injecté là où il sera réellement fait.
Dans chaque cas, les agents n’ont pas remplacé l’expert. Ils ont supprimé la couche d’opérations à faible valeur ajoutée entre l’événement et l’action, et orchestré une séquence que personne n’aurait voulu coder en dur.
La fluidité décrite plus haut peut tromper. En production, ces chaînes ne tournent jamais en pleine autonomie ; elles sont hybrides et supervisées, et c’est volontaire.
Le coût d’abord. Un système d’agents multiplie les appels modèle, un par étape, parfois davantage quand l’agent itère. À l’échelle de centaines de milliers de dossiers par mois, l’addition est sérieuse. La pratique : router intelligemment, un petit modèle pour le tri et la classification, un modèle frontier pour les étapes critiques, et cacher agressivement le récurrent. Un système bien conçu choisit le bon modèle pour chaque étape, pas le plus gros pour tout.
La confiance ensuite. Un modèle correct à 98 % se trompe deux fois sur cent. Pour des actions à fort enjeu, paiement, signature, déclaration fiscale, l’agent d’action ne tranche pas seul : seuil de confiance explicite, seconde passe comparative, ou revue humaine sur les cas limites. L’objectif n’est pas zéro erreur, c’est zéro erreur silencieuse. L’action automatique reste cantonnée aux cas à faible enjeu ou à forte confiance ; le reste passe par un humain. Une chaîne agentique mature n’est pas une chaîne sans humain, c’est une chaîne où l’humain ne traite plus que ce qui compte.
Enfin la traçabilité de l’orchestration. Plus les agents décident eux-mêmes de leur séquence, plus il faut journaliser chaque appel d’outil et chaque décision intermédiaire, pour remonter de la tâche créée jusqu’à l’événement déclencheur. Ce n’est pas un luxe : c’est ce qui rend un système agentique débogable, et donc déployable.
Ce sujet est à l’intersection de nos trois métiers : intégration de données, édition SaaS, et la couche AI Services plus récente. Accompagner un client sur un projet data signifiait construire des connecteurs, modéliser des flux, concevoir des règles métier. Cette compétence reste indispensable, mais elle se déplace : du câblage de pipelines figés vers la conception de systèmes d’agents qui orchestrent des actions.
La valeur que nous apportons ne se mesure plus à la qualité du pipeline livré, mais à notre capacité à raccourcir la distance entre un événement entrant et une action exécutée dans le système d’information du client. C’est la logique de plusieurs projets récents : un assistant légal RAG pour la fiscalité et le droit du travail marocain, des automatisations n8n autour de Gmail, Zoho et de modèles frontier, des comptes rendus de conseil transformés en tâches assignées. À chaque fois : supprimer la couche manuelle entre le déclencheur et l’action, et rendre cette orchestration supervisable et traçable.
Le positionnement pour les douze à vingt-quatre prochains mois tient en trois axes. D’abord, devenir l’intégrateur de référence au Maroc sur les architectures agentiques d’automatisation de processus, là où la majorité des acteurs locaux vendent encore de l’OCR ou des templates rigides. Ensuite, construire des briques SaaS verticalisées (fiscalité, RH, comptabilité) qui empaquettent ces orchestrations pour des clients qui n’ont ni l’envie ni les moyens de les bâtir. Enfin, capitaliser sur la couche hardware historique pour proposer des offres bout-en-bout où capture physique et déclenchement de processus ne sont plus deux projets, mais un seul produit.
Le marché marocain a un avantage ici : assez digitalisé pour que les volumes soient significatifs, assez fragmenté en pratiques locales pour que les solutions internationales out of the box donnent des résultats médiocres. C’est l’espace où un intégrateur local maîtrisant la techno frontier peut bâtir une position défendable.
Le point d’arrivée n’est pas l’IA lit les documents à la place des humains. C’est plus profond : un événement entrant devient le déclencheur d’une chaîne d’actions orchestrée par des agents, et la conception même de l’automatisation des processus s’en trouve renversée. On ne code plus des chemins, on outille des objectifs.
Pour les équipes data, le métier change. L’enjeu n’est plus de construire des pipelines toujours plus sophistiqués, mais de concevoir des systèmes où extraction, enrichissement, décision et action deviennent des agents composables, observables et supervisables. Le data engineer évolue vers une posture d’architecte d’orchestrations métier augmentées par l’IA.
