Un agent IA peut produire une réponse claire, bien écrite et pourtant fausse. Cela arrive souvent quand il ne voit qu’une partie des informations utiles.
Nous ne commençons donc pas un projet par le choix d’un modèle ou d’un outil. Nous commençons par le travail réel : les personnes qui l’exécutent, les données qu’elles utilisent, les étapes qui ralentissent et les vérifications qu’elles font encore à la main.
Cette méthode évite d’automatiser un processus mal compris. Elle permet aussi de décider où l’IA est utile, où une automatisation classique suffit et où la décision doit rester humaine.
Parler d’un processus à auditer
1. Comprendre comment le travail se fait vraiment
Une entreprise possède souvent deux versions du même processus.
La première est le processus déclaré : les étapes prévues, les outils officiels et les responsabilités telles qu’elles ont été définies.
La seconde est le processus pratiqué. Elle comprend les doubles saisies, les fichiers personnels, les validations envoyées par email, les informations transmises oralement et les contournements créés au fil du temps.
Nous avons besoin des deux versions. Un système conçu uniquement à partir du processus déclaré risque de manquer les cas que l’équipe traite tous les jours.
Reconstituer un cas réel
Nos entretiens prennent la forme d’un parcours guidé. Nous demandons aux personnes concernées de nous montrer un dossier récent, de son arrivée à sa clôture.
Nous cherchons notamment à comprendre :
- d’où viennent les informations utilisées au départ ;
- dans quels outils elles sont consultées, copiées ou modifiées ;
- où le travail attend, et qui doit intervenir pour le débloquer ;
- quelles données sont vérifiées avant d’être utilisées ;
- quels fichiers ou tableaux personnels sont devenus indispensables ;
- quelles exceptions prennent plus de temps que prévu ;
- quelle étape céderait en premier si le volume doublait.
Nous échangeons avec les responsables du processus, mais aussi avec les personnes qui l’exécutent. Elles ne décrivent pas toujours les mêmes difficultés, et cette différence nous aide à comprendre le fonctionnement réel.
Cartographier les sources et les silos
Les informations utiles peuvent être réparties entre un CRM, un ERP, des tableurs, des dossiers partagés, une messagerie, un outil métier et la mémoire de quelques collaborateurs.
Pour chaque source, nous relevons ce qu’elle contient, qui l’alimente, qui la consulte, les doublons qu’elle crée et le niveau de confiance que l’équipe lui accorde.
Cette cartographie répond à plusieurs questions :
- Quelle source fait foi lorsqu’une information diffère entre deux outils ?
- Où les collaborateurs ressaisissent-ils la même donnée ?
- Quelles informations restent invisibles pour le reste du système ?
- Quels outils sont utiles, redondants ou peu utilisés ?
- Que se passe-t-il lorsqu’une personne clé est absente ?
L’objectif n’est pas de remplacer tout l’environnement existant. Certains outils doivent rester en place. D’autres doivent être connectés, simplifiés ou retirés.
Chiffrer le problème avec vos données
Nous attachons un indicateur aux difficultés qui peuvent être mesurées : temps de saisie, délai d’attente, fréquence des erreurs, coût des reprises, dossiers retardés ou capacité perdue.
Nous n’utilisons pas une moyenne sectorielle pour annoncer un retour sur investissement. Le point de départ vient de vos volumes, de vos délais et du coût réel du travail concerné.
Ce chiffrage permet de comparer les cas d’usage sans arbitrer uniquement à l’intuition. Un projet spectaculaire n’est pas toujours le projet le plus utile.
Ce que vous recevez après le diagnostic
Le périmètre varie selon la mission, mais le diagnostic peut comprendre :
- la carte du processus actuel et de ses points de passage ;
- l’inventaire des sources, outils et dépendances ;
- les problèmes observés et les indicateurs disponibles ;
- les cas d’usage classés par impact, faisabilité et risque ;
- une proposition d’architecture cible ;
- une stratégie de migration si le processus change d’outil ;
- un plan de mise en œuvre par étapes ;
- les indicateurs qui serviront à évaluer le résultat.
Durée habituelle : une à deux semaines, selon le nombre de processus, d’outils et d’équipes concernés.
2. Concevoir le système avant de le construire
Le diagnostic indique ce qu’il faut traiter. La phase de conception précise comment les données circuleront, quelles actions seront automatisées et où placer les validations humaines.
Une source de référence pour chaque donnée critique
Une information importante doit avoir une source de référence clairement désignée. Les autres outils peuvent la consulter ou la compléter selon des règles définies, mais ils ne doivent pas recréer plusieurs versions concurrentes de la même information.
Nous définissons donc :
- où chaque donnée est créée ;
- qui peut la modifier ;
- quels systèmes peuvent seulement la lire ;
- comment les erreurs et les doublons sont détectés ;
- combien de temps l’information doit être conservée.
Cette étape précède les agents. Un agent connecté à trois versions différentes du statut d’un client ne peut pas deviner laquelle est correcte.
Automatisation, agent IA ou humain
Nous répartissons le travail selon sa nature.
| Type de travail | Traitement recommandé |
|---|---|
| La règle peut être écrite complètement et doit toujours produire le même résultat | Automatisation déterministe |
| La tâche demande de lire, classer, rechercher, résumer ou rédiger à partir d’un contexte | Agent IA |
| L’action engage l’entreprise, comporte un risque important ou demande un arbitrage métier | Décision humaine préparée par le système |
Par exemple, créer une fiche après la réception d’un formulaire ne demande pas forcément d’IA. Classer un email selon son contenu peut justifier un agent. Accepter un devis, valider une réponse à un appel d’offres ou traiter une exception sensible reste une décision humaine.
Ajouter de l’IA à une règle stable augmente le coût et l’incertitude sans apporter de valeur. Nous l’utilisons lorsque l’interprétation apporte quelque chose.
Conserver, connecter, remplacer ou supprimer
Chaque outil du processus passe par quatre questions :
- Faut-il le conserver parce qu’il remplit bien son rôle ?
- Faut-il le connecter pour éviter une ressaisie ou un manque d’information ?
- Faut-il remplacer une fonction devenue redondante ?
- Faut-il supprimer un outil qui n’a plus d’usage vérifiable ?
Cette décision évite les reconstructions inutiles. Dans beaucoup de projets, l’architecture cible conserve la messagerie, l’outil comptable ou le logiciel métier, puis ajoute une couche de coordination autour d’eux.
3. Construire dans le bon ordre
Nous avançons par étapes. Chaque étape possède un critère de validation avant le début de la suivante.
Données et droits d’accès
Nous commençons par les structures de données, les sources de référence, les permissions et les règles de conservation. Les entrées sont contrôlées au moment où elles arrivent, plutôt qu’au moment du reporting.
Workflows
Nous mettons ensuite en place les actions déterministes : réception, création d’un dossier, attribution, changement de statut, validation, notification et journalisation.
Ces workflows forment le circuit sur lequel l’agent pourra s’appuyer. Ils doivent fonctionner proprement avant d’ajouter une couche d’interprétation.
Agents IA
L’agent arrive lorsque ses sources, ses droits et son rôle sont définis. Nous précisons ce qu’il peut lire, proposer ou exécuter. Nous définissons également les situations dans lesquelles il doit s’arrêter, signaler une incertitude ou demander une validation.
Tests sur des cas réalistes
Nous testons le système sur quatre dimensions :
- le fonctionnement technique des déclencheurs, permissions et intégrations ;
- les données manquantes, doublons, mauvais formats et volumes inhabituels ;
- la facilité d’utilisation pour les personnes qui feront réellement le travail ;
- la stabilité des réponses de l’agent sur un jeu de cas représentatif.
Un test ne sert pas seulement à vérifier le parcours normal. Les cas limites révèlent souvent les défauts qui auraient produit les erreurs les plus coûteuses en production.
Durée habituelle du prototype : deux à quatre semaines. La mise en production dépend ensuite des intégrations, des cas limites et du niveau de sécurité attendu.
4. Préparer la migration et la bascule
Un nouvel outil échoue souvent lorsque l’ancien reste actif sans règle claire. L’équipe finit alors par travailler dans les deux systèmes, puis revient vers celui qu’elle connaît le mieux.
Nous choisissons la stratégie de migration pendant la conception.
Migration complète
Les données historiques sont nettoyées, rapprochées du nouveau modèle puis importées. Cette option convient lorsque l’historique reste nécessaire au travail quotidien, au reporting ou à une obligation de conservation.
Bascule à une date donnée
Tous les nouveaux dossiers créés après une date précise utilisent le nouveau système. Les dossiers déjà ouverts se terminent dans l’ancien. Cette solution évite une migration coûteuse lorsque les cycles de travail sont courts et que l’historique est rarement consulté.
Migration hybride
Les référentiels durables, par exemple les clients, contacts, fournisseurs ou catalogues, sont migrés. Les anciennes opérations restent accessibles en lecture seule ou finissent leur cycle dans l’ancien système.
Dans les trois cas, l’équipe connaît la date de bascule, reçoit sa formation avant cette date et sait quel outil fait foi. Les anciens outils sont fermés ou placés en lecture seule selon le calendrier convenu.
5. Accompagner l’adoption
La livraison technique ne suffit pas. Nous vérifions que les workflows prévus passent réellement par le nouveau système.
Le taux d’adoption correspond à la part des workflows concernés qui utilisent le dispositif en production, sans retour durable vers un circuit parallèle.
Le tableur parallèle est un signal utile
Une personne peut continuer son ancien tableau par précaution. Ce comportement indique généralement l’un de ces problèmes :
- le nouveau système ne couvre pas un cas fréquent ;
- certaines données ne sont pas encore jugées fiables ;
- la personne n’a pas reçu la formation adaptée à son rôle ;
- une étape demande plus d’effort qu’avant.
Nous traitons ce tableau comme une information sur le système, pas comme une faute de l’utilisateur. Plus le problème est observé tôt, plus il est facile à corriger.
Former selon les rôles
Chaque équipe apprend les workflows qu’elle utilisera. Les sessions sont enregistrées lorsque cela est utile, et la documentation doit permettre à une nouvelle personne de reprendre le système sans dépendre de son développeur.
Le suivi post-déploiement couvre les premiers usages, les erreurs, les demandes de contournement et les ajustements nécessaires.
6. Maintenir et améliorer ce qui tourne
L’entreprise change après la mise en production. Les volumes augmentent, de nouveaux cas apparaissent, les outils évoluent et les équipes changent.
Nous suivons quatre sources d’information :
- l’usage réel des workflows et des fonctions ;
- les erreurs techniques et les échecs d’authentification ;
- les retours des personnes qui utilisent le système ;
- les changements de règles, d’organisation ou de volume.
Chaque automatisation importante doit laisser une trace. Lorsqu’une étape échoue, l’échec doit être visible et transmis à la bonne personne. Une automatisation silencieusement arrêtée depuis plusieurs semaines est plus dangereuse qu’une erreur immédiatement signalée.
Les revues périodiques servent à décider quoi corriger, simplifier ou ajouter. Une fonction peu utilisée n’est pas automatiquement inutile, mais elle mérite d’être examinée avec les utilisateurs concernés.
Ce que cette méthode évite
Elle réduit cinq risques fréquents :
- construire à partir d’une version théorique du processus ;
- automatiser un fonctionnement déjà défaillant ;
- choisir les outils avant d’avoir défini l’architecture ;
- connecter un agent à des données fragmentées ;
- lancer un nouveau système sans responsable, formation ni date de bascule.
Aucun de ces problèmes ne se corrige avec un meilleur prompt. Ils demandent du cadrage, des responsabilités claires et des contrôles vérifiables.
Commencer par un processus concret
Un premier projet se prête mieux à l’IA lorsque son périmètre est clair, que le travail se répète et que le résultat peut être vérifié.
Lors d’un premier échange, nous examinons le processus, les outils concernés, les données disponibles et le niveau de contrôle nécessaire. Si une automatisation classique suffit, nous le disons. Si les données ne permettent pas encore de construire un agent fiable, nous commençons par ce problème.
Auditer un processus avec Levolia
Certifications et expertises reconnues
Notre pratique est encadrée par des certifications vérifiables, pas par des logos.
- Lovable Certified Expert (App builder 2026) : certification d’expertise sur la construction d’applications avec Lovable. Elle porte sur le travail que nous menons sur nos propres produits et sur les applications que nous construisons pour nos clients.
Cette certification complète notre méthode de déploiement : lorsqu’une interface ou une application interne est nécessaire, nous la construisons dans le même cadre de contrôle que le reste du système.