Automatisation IA à Paris

Ceux dont les règles sont instables, dont les données sont insuffisantes ou dont les conséquences d’erreur sont disproportionnées par rapport au gain attendu.

Trois cas se refusent clairement. Un processus en cours de refonte : automatiser une organisation qui va changer dans six mois produit un outil à jeter. Un processus dont l’exception est la règle — si soixante pour cent des dossiers sortent du cas nominal, l’automatisation traite une minorité et complique le reste. Et un processus où une erreur engage juridiquement ou financièrement sans possibilité de correction.

Un quatrième cas est plus subtil : les processus où le travail apparent masque une décision. Une personne qui « recopie des informations » vérifie souvent en même temps leur cohérence, et ce contrôle disparaît avec la recopie. Le gain est réel et le risque aussi ; il faut le nommer.

À l’inverse, les bons candidats se reconnaissent vite : volume élevé, règles stables, erreur visible et peu coûteuse, et une personne qui décrit son travail comme répétitif sans jugement à porter.

Un workflow suit un enchaînement déterminé. Un agent choisit ses actions selon le contexte, ce qui demande des garde-fous, des limites et une traçabilité.

Le workflow est prévisible et testable : si la facture contient tel champ, alors telle action. Il traite mal ce qui n’a pas été prévu, et c’est sa seule faiblesse. Pour la majorité des automatisations d’entreprise, c’est le bon outil — moins cher, plus fiable, plus facile à corriger.

L’agent décide de la suite en fonction de ce qu’il rencontre : lire un document, appeler un service, demander une précision, recommencer. Cette souplesse sert quand le chemin dépend du contenu — un dossier dont les pièces varient, une demande dont la nature n’est pas connue d’avance.

Elle coûte deux choses. La prévisibilité : deux exécutions sur le même dossier peuvent différer. Et la traçabilité, qui devient obligatoire : chaque décision de l’agent doit être journalisée pour être relue.

Nous employons donc un agent seulement là où le workflow échoue, et jamais pour la partie qui déclenche une action irréversible.

Par une détection explicite, une file de traitement humain et une amélioration continue des règles à partir des cas rencontrés.

Le principe : un système automatisé doit savoir quand il ne sait pas. Un seuil de confiance en dessous duquel le dossier part en file humaine vaut mieux qu’une décision prise sur une base fragile. Ce seuil se règle après quelques semaines d’observation, pas au premier jour.

La file humaine n’est pas un échec du projet, elle en fait partie. Un dispositif qui traite quatre-vingts pour cent des cas et route proprement les vingt restants apporte plus qu’un dispositif qui prétend tout traiter et se trompe sur les cas difficiles.

Le cycle d’amélioration compte autant : chaque cas traité manuellement est examiné, et s’il révèle une règle manquante, la règle est ajoutée puis testée sur l’historique. La part automatisée progresse ainsi de mois en mois, de manière mesurable.

Nous exposons donc le taux de traitement automatique et la composition de la file dans un tableau de bord, parce que c’est l’indicateur qui dit si le projet vit.

Non. L’automatisation s’articule avec vos outils existants en traitant ce qu’ils ne couvrent pas, sans dupliquer une fonction déjà assurée.

La règle que nous appliquons : la donnée reste dans le système qui en est la référence. L’automatisation lit, décide, et écrit dans ce système — elle ne constitue pas une base parallèle. Dupliquer garantit une divergence en quelques semaines, et une divergence entre l’ERP et un outil annexe se termine toujours par l’abandon de l’outil annexe.

Ce que l’automatisation apporte se situe dans les interstices : la lecture d’un document entrant pour en extraire les informations qu’une personne recopiait, le classement d’une demande vers le bon service, la préparation d’une réponse, le rapprochement de deux sources.

Un cas justifie de construire à côté : la fonction existe dans votre outil mais son coût de licence par utilisateur rend son ouverture à cent personnes déraisonnable. C’est un argument économique, pas technique, et il est légitime.

Le cadrage produit une carte d’une page : ce qui reste où, et les échanges entre les deux.

Lorsque la décision engage financièrement, juridiquement ou contractuellement, ou lorsque l’erreur n’est pas détectable a posteriori.

Le critère décisif est la réversibilité. Une classification erronée se corrige en reclassant. Un courriel envoyé à un client ne se rattrape pas. Un remboursement exécuté ne s’annule pas sans intervention. Nous plaçons donc la validation humaine avant les actions irréversibles et visibles de l’extérieur, et nous laissons le reste automatique.

Le second critère est la détectabilité. Une erreur qui se voit — un dossier mal rangé — est acceptable parce qu’elle sera corrigée. Une erreur silencieuse qui s’accumule — un montant mal extrait sur un dossier sur cent — coûte davantage et justifie un contrôle par échantillon même sur une tâche automatisée.

S’y ajoute le cadre réglementaire : sur les usages classés à risque élevé par le règlement européen, un contrôle humain effectif est une obligation, et « effectif » signifie que la personne a les moyens et le temps de contredire — pas un bouton d’approbation sur trois cents dossiers par jour.

Cette frontière est écrite au cadrage.

Par des identifiants d’exécution, des contrôles d’idempotence, des journaux et des mécanismes de reprise sûrs.

Le problème est réel et fréquent : un traitement interrompu puis relancé peut refaire ce qu’il avait déjà fait. Un courriel envoyé deux fois, une commande créée deux fois, un paiement déclenché deux fois.

La protection repose sur une clé d’unicité portée par l’opération : le système cible refuse une seconde fois la même clé, ce qui rend le rejeu inoffensif. Cette contrainte doit exister du côté de votre ERP ou de votre CRM, et sa vérification fait partie du cadrage — c’est un point qui bloque parfois, quand le système cible ne l’offre pas.

À défaut, un registre local des opérations déjà exécutées joue le même rôle, avec une fiabilité moindre.

S’y ajoutent des journaux complets — quelle opération, sur quel dossier, à quelle heure, avec quel résultat — et une reprise qui repart de la dernière opération confirmée plutôt que du début. Un traitement par lots qui échoue à quatre-vingt-dix pour cent et redémarre de zéro produit exactement les doublons qu’on cherche à éviter.

Par le temps libéré, la réduction des erreurs, les délais de traitement et la part de cas traités sans intervention humaine.

Quatre indicateurs relevés avant et après, l’avant étant le point que les projets oublient. Le temps de traitement par dossier, mesuré sur un échantillon réel plutôt qu’estimé. Le délai entre l’arrivée d’une demande et sa résolution, souvent plus parlant que le temps de travail. Le taux d’erreur constaté en aval. Et la part de cas traités sans intervention, qui est l’indicateur de vie du dispositif.

Le gain se lit rarement en suppression de poste et presque toujours en déplacement d’activité : le temps libéré va au traitement des cas difficiles, au rappel des clients, ou à ce qui était en retard. C’est un gain réel et il faut le formuler ainsi plutôt que de promettre une économie de masse salariale qui n’arrivera pas.

Nous suivons aussi un indicateur négatif : le temps passé à corriger les erreurs du système. S’il dépasse le temps économisé, le dispositif est un coût, et nous le disons.

La maintenance peut être assurée par Novatis ou par vos équipes, avec la documentation, les accès et la supervision nécessaires.

Une automatisation demande plus de suivi qu’une application classique, pour une raison précise : elle dépend de systèmes extérieurs qui changent sans vous prévenir. Une interface d’ERP qui évolue, un format de document fournisseur qui se modifie, un modèle dont la version est retirée par son éditeur. Le dispositif casse sans qu’on ait touché à son code.

La supervision est donc l’élément principal : volume traité par jour, taux de succès, taille de la file d’exception, délai moyen. Une variation de ces chiffres signale un problème avant que quelqu’un ne le remarque dans son travail. Sans supervision, une automatisation arrêtée passe inaperçue plusieurs jours — c’est l’incident silencieux le plus courant.

Les coûts récurrents sont dits au devis : l’appel aux modèles se facture à l’usage, et un volume qui double double la facture. Nous plafonnons donc la dépense mensuelle avec une alerte, plutôt que de découvrir le montant en fin de mois.