Audit avant un projet IA : écrire les règles métier d'abord

Quand un dirigeant nous appelle pour automatiser un processus, il arrive souvent avec une solution en tête : un outil, un agent IA, une intégration avec l'ERP. Il arrive rarement avec les règles écrites. C'est normal, elles ne l'ont presque jamais été. C'est pourtant là que le projet se gagne ou se perd.

Pourquoi ne pas commencer directement par le développement ?

Parce qu'un développeur code ce qu'on lui décrit, et que le processus décrit en réunion n'est presque jamais le processus réel. En réunion, on présente le cas standard. Dans la réalité, il y a les exceptions : le client qui a une marge différente, le produit qui n'a pas de donnée logistique, la règle ajoutée après un litige et que personne n'a notée.

Découvrir ces exceptions pendant le développement coûte cher. On réécrit, on retarde, et l'équipe métier perd confiance dans l'outil avant même de l'avoir utilisé. Les découvrir pendant un audit coûte quelques entretiens et quelques pages.

C'est la méthode que nous suivons sur chaque projet, et nous avons accompagné 37 entreprises à ce jour : un audit, un cadrage de ce qu'on construit, puis un premier livrable, des retours terrain et des itérations.

Que cherche-t-on pendant un audit ?

L'écart entre ce que l'entreprise croit faire et ce qu'elle fait. Concrètement, on veut savoir :

• d'où viennent les données, et laquelle fait foi quand deux sources se contredisent ;
• qui détient les règles, et si elles sont écrites quelque part ;
• où part le temps, étape par étape ;
• ce qui s'arrête quand une personne est absente ;
• ce qui existe déjà et doit être conservé : ERP, fichiers, habitudes des clients.

L'audit sert aussi à dire où l'IA ou un développement sur-mesure apporte quelque chose, et où il n'apporte rien. Un bon audit élimine des idées autant qu'il en retient.

Ce que l'audit a révélé chez un distributeur de câbles

Ce client distribue des câbles entre l'Europe et l'Asie, en euros, dollars et yuans, avec plus de 3 000 références dont une part significative est indexée sur le cuivre. Le pricing reposait sur des fichiers Excel mis à jour à la main, avec une chaîne de calcul répartie sur plusieurs feuilles. Le projet est détaillé dans notre article sur l'automatisation du pricing B2B.

L'audit a d'abord mis des mots sur le problème. Toutes les règles de calcul étaient détenues par une seule personne, sans documentation. Une part importante de son temps partait chaque mois dans la saisie et la vérification des prix. Et l'équipe pricing ne pouvait pas grandir, puisque former quelqu'un supposait de transmettre un processus jamais écrit. Ce risque de dépendance a son propre article : quand une seule personne connaît toutes les règles de prix.

Il a ensuite changé l'ordre du projet. Les produits vivaient à la fois dans l'ERP et dans des fichiers Excel, pas tous à jour. Un moteur de prix branché sur ce catalogue aurait produit des prix faux, plus vite. La première brique a donc été une base produit unique, synchronisée chaque jour avec l'ERP pour les stocks et les prix d'achat, avant le moteur de calcul lui-même.

Enfin, il a montré ce qu'il ne fallait pas toucher. L'ERP est resté en place. Les équipes et leurs clients travaillaient en Excel : l'import et l'export ont été gardés, et les offres sortent toujours dans ce format. Supprimer Excel aurait paru plus propre sur le papier, et aurait freiné l'adoption.

Pourquoi le cadrage doit-il être écrit ?

Parce qu'une règle écrite peut être relue, contestée et testée. Une règle orale ne peut qu'être crue.

Pour un moteur de pricing, le cadrage décrit chaque étape du calcul dans l'ordre : prix fournisseur, cours du cuivre, conversion de devise, transport, douane, marge. Il précise les options, par exemple appliquer la marge d'achat avant ou après le transport, un besoin propre à ce client que le moteur devait prévoir. Il dit aussi ce qui se passe quand une donnée manque. Chez notre client, un produit sans quantité par palette est calculé sans coût de transport, et une alerte l'indique. Ce genre de règle, personne ne la formule spontanément en réunion.

Le document devient ensuite la référence pour la recette. Si le moteur ne donne pas le résultat attendu sur un cas décrit, on sait tout de suite si l'erreur est dans le code ou dans la règle. Sans document, la discussion tourne à la parole contre parole.

Que doit contenir un bon cadrage ?

Si vous préparez un projet, vérifiez que le document répond à ces questions :

1. Quelles sont les entrées, et d'où vient chacune ?
2. Quelles sont les étapes de calcul ou de décision, dans l'ordre ?
3. Quelles exceptions existent, avec un exemple réel pour chacune ?
4. Que fait le système quand une donnée manque ou paraît incohérente ?
5. Quels paramètres l'équipe doit-elle pouvoir modifier seule, sans développeur ?
6. Quelle sortie est attendue, dans quel format, et pour qui ?
7. Qu'est-ce qui reste hors du premier lot ?

La dernière question compte plus qu'on ne le croit. Le cadrage sert aussi à choisir ce qu'on livre en premier ; nous détaillons ce découpage dans notre article sur le MVP d'un projet d'automatisation.

La question 5 mérite aussi qu'on s'y arrête. Chez ce distributeur, le cours du cuivre, le taux de change, le transport, la douane et la marge sont des paramètres que l'équipe modifie elle-même, et elle peut ajouter des champs produit sans développement. Si le cadrage ne le prévoit pas, chaque évolution vous ramène chez le prestataire.

Un audit ne ralentit-il pas le projet ?

Il retarde le début du code, pas forcément la mise en production. Le temps passé à écrire les règles est du temps que le développement n'aura pas à passer à les deviner, puis à les corriger.

Le document reste aussi à l'entreprise. Même sans aller plus loin, elle dispose d'une description écrite de son processus, qu'elle peut transmettre à un nouveau collaborateur ou à un autre prestataire.

C'est enfin le bon moment pour décider s'il faut développer ou acheter. Une fois les règles écrites, on voit vite si un logiciel du marché les couvre. Notre comparatif développer sur-mesure ou acheter donne les critères.

Par quoi commencer, avant même de parler à un prestataire ?

Prenez cinq offres récentes et demandez à la personne qui les a faites d'expliquer chaque prix, ligne par ligne, pendant que quelqu'un d'autre prend des notes. Les règles non écrites apparaissent vite, et vous aurez la première page de votre cadrage.

Si vous voulez faire l'exercice avec nous, c'est l'objet du diagnostic gratuit. Et pour voir ce que donne un cadrage mené jusqu'au bout, la démonstration en vidéo montre la plateforme en production chez ce distributeur.