Automatisation des processus pour PME belges

Chaque projet commence en suivant une seule demande, de son arrivée jusqu’à son traitement final. Qui y touche, par quels outils elle passe, où la même information est réencodée une deuxième fois, et quels cas sont discrètement traités à la main. Ce qui ressemble à un processus en cache généralement trois, tenus ensemble par des exceptions que personne n’a jamais écrites parce que tout le monde les connaît déjà.

Cette cartographie change souvent la demande de départ. Ce qui coûte cher, ce n’est pas le travail lui-même mais l’attente entre les étapes : une demande qui dort deux jours dans une boîte mail parce que personne ne savait qu’elle était arrivée. Parfois, un seul champ validé à la source évite plus de corrections qu’une grosse automatisation. Nous préférons vous le dire la première semaine plutôt que construire ce qui a été demandé et regarder un processus bancal tourner plus vite.

Vous avez déjà un CRM, une boîte mail, un logiciel comptable et quelques formulaires. Le travail consiste à les faire s’accorder entre eux. Quand une API propre existe, nous l’utilisons. Sinon, il y a généralement un webhook, un export planifié, ou un e-mail ou PDF structuré à analyser. Vous saurez lequel de ces chemins est fragile avant que quelque chose d’important n’en dépende.

Chaque connexion reçoit une source de vérité unique et une réponse décidée pour les mauvais jours, parce qu’ils arrivent. Des messages sont livrés deux fois. Un service est indisponible pendant une heure. Un fichier arrive sans un champ qu’il a toujours eu. Un processus qui n’a pas décidé quoi faire à ces moments-là n’échoue pas bruyamment : il échoue en silence, et vous l’apprenez des semaines plus tard par un client. Les reprises, les étapes qu’on peut rejouer sans risque et une file d’attente pour tout ce qui demande un œil humain font partie de la construction, pas d’une phase ultérieure.

Les modèles de langage sont bons pour une catégorie de travail : lire une entrée désordonnée et la transformer en quelque chose de structuré. Trier ce qui arrive, extraire des champs de factures qui ne se ressemblent jamais, résumer un long fil de discussion, rédiger une première réponse, répondre à partir de vos propres documents. Un modèle reçoit une seule tâche, le minimum de contexte nécessaire, et un format de sortie que le reste du système peut vérifier avant d’agir.

Tout le reste demeure du code ordinaire. Droits d’accès, totaux, règles métier, tout ce qui est irréversible : cela doit se comporter identiquement à chaque fois, et un modèle ne l’offre pas. Le niveau de contrôle suit le coût de l’erreur. Un e-mail mal classé ne coûte rien. Un paiement ou une promesse faite à un client attend une personne. Là où ça compte, les prompts, les versions de modèle et les résultats sont journalisés, pour qu’un mauvais résultat puisse être expliqué plutôt que deviné.

Les modèles sont aussi remplacés tous les quelques mois. Les garder derrière une interface étroite fait qu’en changer prend un après-midi plutôt qu’une reconstruction.

Avant que quoi que ce soit ne tourne, nous écrivons ce que chaque étape touche, où cela circule et qui peut le lire. Les identifiants sont séparés par environnement et limités aux droits que le processus utilise, rarement ceux qu’il était pratique de créer. Les données sensibles peuvent être anonymisées avant de sortir, envoyées uniquement à un fournisseur que vous avez approuvé, ou tenues complètement à l’écart des services d’IA. Une grande partie des automatisations utiles n’implique aucun modèle.

Quand les données ne peuvent vraiment pas sortir, des composants auto-hébergés sont une option réelle, et nous le dirons avant que tout ne passe par défaut par l’API la plus proche. La conservation suit ce que l’entreprise et le RGPD exigent réellement, pas ce qu’un outil propose par défaut. C’est la partie pénible à rattraper après coup, donc elle vient avant la construction.

Trois échecs reviennent sans cesse. Le premier : automatiser un processus qu’il aurait fallu supprimer. Le deuxième : un processus sans responsable, qui pourrit dès qu’un fournisseur change un format d’export. Le troisième : une intégration bâtie sur quelque chose de non documenté, une page aspirée ou un point d’accès officieux, qui fonctionne très bien jusqu’au jour où non.

Aucun n’est exotique et tous sont évitables. Supprimer d’abord, automatiser ensuite. Désigner un responsable avant la mise en service. Construire sur des interfaces réellement supportées par l’éditeur, et lorsqu’un chemin fragile est le seul possible, le traiter comme un risque connu avec une surveillance dessus. Une ligne dans un document de reprise que personne ne lit ne protège de rien.

Un processus automatisé devrait être plus facile à observer que le travail manuel qu’il remplace. Son état actuel se trouve là où l’équipe regarde déjà. Les exceptions arrivent avec assez de contexte pour que la personne responsable les traite sans appeler un développeur. N’importe qui peut mettre un flux en pause, corriger une donnée et le laisser repartir.

Nous fixons une base de référence avant la mise en service (temps de traitement, arriéré, taux d’erreur, nombre de cas qui demandent encore un humain) pour qu’il y ait ensuite quelque chose d’honnête à comparer. Tous les chiffres ne bougent pas, et ceux qui ne bougent pas méritent d’être connus. Ce qui est remis avec le processus :