On m'a demandé plusieurs fois cette année s'il fallait « faire un audit data » avant de lancer quoi que ce soit. La réponse honnête, pour une PME, est presque toujours non. Un audit data complet mobilise des semaines, produit un rapport épais, et arrive à une conclusion que trois tests suffisent à obtenir en une matinée. Ces trois tests, je les fais chez le client, sur son poste, avec ses fichiers.
Test 1 — Une personne peut-elle extraire la donnée en moins d'une heure ?
Pas « est-ce qu'on pourrait ». Pas « il doit y avoir un export quelque part ». Tu prends quelqu'un de l'équipe, tu lui demandes le fichier, et tu regardes ta montre.
Ce que ce test mesure vraiment, ce n'est pas la difficulté technique. C'est l'existence d'un chemin d'accès connu. Une donnée dont l'extraction demande d'ouvrir un ticket au prestataire du logiciel métier, d'attendre trois jours et de payer une intervention n'est pas une donnée disponible : c'est une donnée théorique. Tu ne pourras pas itérer dessus, et itérer est exactement ce que tu vas devoir faire.
Les échecs typiques que je rencontre :
- L'information vit dans des boîtes mail individuelles. Personne ne peut la sortir sans demander à cinq personnes.
- Le logiciel métier n'a ni API ni export, seulement des écrans. On peut copier-coller, pas automatiser.
- L'export existe mais il est faux : il tronque, il perd les accents, il ignore les lignes archivées. Ça se voit à l'ouverture, jamais dans la documentation.
Si tu échoues à ce test, ta première brique IA n'est pas une brique IA. C'est un chantier d'accès à la donnée, et il vaut le coup d'être fait pour lui-même.
Test 2 — Deux personnes donnent-elles la même réponse à partir de la même donnée ?
Celui-ci est plus subtil et c'est celui qui élimine le plus de projets.
Le protocole : tu prends dix cas réels — dix dossiers, dix demandes, dix devis. Tu les donnes séparément à deux personnes expérimentées de la même équipe, avec la même question. « Ce lead est-il qualifié ? » « Ce dossier est-il complet ? » « Cette réclamation est-elle recevable ? » Puis tu compares.
Si les deux réponses concordent sur neuf cas sur dix, tu as une règle implicite mais stable. Elle peut être explicitée, donc automatisée.
Si elles divergent sur quatre cas, tu n'as pas un problème de données : tu as un problème de définition. Et là, l'IA est le pire outil possible, parce qu'elle produira une troisième réponse, formulée avec assurance, sans que personne puisse dire si elle est juste. Tu ne mesures plus rien.
Quand deux experts ne sont pas d'accord sur ce qu'est un bon dossier, aucun modèle ne le sera à leur place.
Le bon réflexe quand le test échoue : réunir les deux personnes, prendre les cas de désaccord un par un, et écrire la règle. Cette réunion dure deux heures et vaut plus que six semaines de développement.
Test 3 — La donnée est-elle à jour à l'échelle de la décision ?
Une donnée n'est pas fraîche ou périmée dans l'absolu. Elle l'est par rapport au rythme de ce qu'elle sert à décider.
Un stock mis à jour toutes les nuits suffit largement pour un réapprovisionnement hebdomadaire. Le même stock, à la nuit près, est inutilisable pour dire à un client si l'article est disponible maintenant. Même donnée, même qualité, deux verdicts opposés.
Pose donc la question dans ce sens :
- À quelle fréquence la décision est-elle prise ?
- Quel est le délai réel entre l'événement dans le monde et son enregistrement dans le système ?
- Que coûte une décision prise sur une donnée périmée ?
Le piège que je vois le plus souvent, c'est le décalage de saisie. Le système est mis à jour en fin de journée, ou en fin de semaine, par une personne qui ressaisit à la main. Techniquement la donnée est là. Opérationnellement, elle a toujours plusieurs heures de retard, et l'agent qu'on veut construire va répondre à côté sans jamais s'en apercevoir.
Ce que ces tests doivent à une expérience de terrain
Cette grille vient largement de mon travail chez La Poste Groupe, sur une solution de données destinée aux e-commerçants : centralisation multi-canaux, KPI, moteur de recommandations personnalisées. Le sujet était présenté comme un sujet d'algorithme. En pratique, l'essentiel de la difficulté portait sur la centralisation : faire converger des canaux qui ne parlaient pas le même langage, décider ce qui faisait référence quand deux sources se contredisaient, et accepter que certaines informations arrivaient avec un délai incompressible.
Une recommandation personnalisée ne vaut que ce que vaut la fraîcheur et la cohérence de ce qui l'alimente. Ce constat n'a pas changé avec l'arrivée des modèles de langage — il s'est juste rendu plus difficile à voir, parce qu'un modèle produit toujours une sortie présentable.
Ce que ces tests ne disent pas
Ils ne disent pas si le projet a du sens économique. Ils ne disent pas si le processus mérite d'être automatisé. Ils répondent à une seule question : est-ce que la matière existe.
Ils ne remplacent pas non plus un vrai travail de gouvernance de la donnée si tu manipules des données personnelles ou sensibles. Sur ce terrain, fais-toi accompagner — ce que j'écris ici n'est pas un avis juridique.
À faire cette semaine
Choisis le processus que tu voulais confier à l'IA. Demande le fichier aujourd'hui, en vrai. Prends dix cas et fais-les trancher par deux personnes. Compare les délais de mise à jour au rythme de la décision.
Trois demi-journées, aucun budget, et tu sauras si tu peux démarrer — ou exactement quoi réparer avant.