Trois projets, et la solution retenue pour chacun.

Le contexte. Un établissement d'enseignement supérieur, plusieurs milliers d'étudiants, cinq systèmes à alimenter à chaque rentrée : ERP de scolarité, suite collaborative, plateforme pédagogique, outil de tickets, annuaire.

Le problème. Le provisionnement se faisait par exports et imports manuels, avec des reprises à la main pour les cas particuliers. Chaque écart entre systèmes générait un ticket de support, au moment précis où les équipes étaient le moins disponibles pour le traiter.

Ce qui a été fait. Une chaîne d'automatisation prenant l'ERP comme référence unique, propageant créations, modifications et désactivations vers les quatre autres systèmes, avec rapport d'écarts et reprise sur erreur. Aucune IA dans cette chaîne : des règles explicites et un journal complet, parce que ce traitement doit être exact à chaque exécution.

Le résultat. Le provisionnement d'une rentrée se traite en quelques heures avec un état des écarts vérifiable. Les équipes de scolarité ont récupéré la période de rentrée pour l'accueil des étudiants.

Le contexte. Une société de services recevant chaque mois plusieurs centaines de documents entrants sous des formes très variées : factures fournisseurs, contrats, formulaires remplis à la main.

Le problème. La saisie était manuelle, avec un taux d'erreur qui augmentait sur les périodes chargées. Les documents non conformes remontaient tard, parfois après paiement.

Ce qui a été fait. Un agent qui lit le document, en extrait les données utiles, les confronte au référentiel fournisseurs et signale les anomalies. La validation reste humaine sur tout ce qui engage un paiement : l'agent prépare, il ne décide pas.

Le résultat. La saisie est devenue une vérification. Les documents non conformes sont identifiés à l'arrivée plutôt qu'après traitement, ce qui a supprimé les régularisations en aval.

Le contexte. Une organisation dont le support recevait un volume important de demandes répétitives, très concentrées sur certaines périodes, avec une base de connaissances existante mais peu consultée.

Le problème. Les équipes passaient l'essentiel de leur temps sur des questions dont la réponse était déjà écrite, ce qui retardait le traitement des demandes réellement complexes.

Ce qui a été fait. Un assistant conversationnel branché sur la base de connaissances et sur l'outil de ticketing, avec une règle stricte : il répond quand la réponse existe, et il escalade en créant un ticket documenté dès que la demande sort du cadre. Le corpus a été remis à jour avant la mise en service, ce qui était la condition du projet.

Le résultat. Les demandes récurrentes sont traitées immédiatement, y compris hors heures ouvrées. Les équipes reçoivent des tickets déjà qualifiés, avec le contexte de la conversation.