Checklist pour préparer les données de l'entreprise avant de les confier à un agent IA : listes de référence, normalisation, processus, rôles — et les erreurs qui ruinent le projet.

Résumé

Question	Réponse courte
Puis-je simplement connecter mes fichiers à un agent IA et le laisser se débrouiller ?	Vous pouvez — et il produira des réponses assurées construites sur des données contradictoires. Ne le faites pas
Par quoi commencer ?	Choisissez un processus et mesurez son coût actuel (heures, erreurs, argent). Tout le reste sert cela
Qu’est-ce que les « données de référence » ?	Les listes sur lesquelles tourne l’entreprise : clients, produits, prix, statuts, unités. Une version canonique de chacune, avec un responsable nommé
Combien d’historique transmettre ?	Les 3–6 mois actifs. Les années antérieures sont un projet de migration, pas le travail d’un agent
Qu’est-ce qui prouve que l’agent fonctionne ?	Un jeu de tests : 20–50 cas réels dont on connaît la bonne réponse, vérifiés après chaque changement
La plus grosse erreur ?	Le texte libre là où devrait figurer une liste contrôlée — des statuts comme « à peu près payé », des couleurs comme données, une feuille par mois

L’argument sonne irrésistible : connectez Google Drive ou SharePoint, et un agent IA lit vos tableurs, répond aux questions et pilote vos opérations. La page AgentKit d’OpenAI elle-même promet des agents qu’on « construit et itère visuellement » (annonce). La démo fonctionne toujours. Puis arrive le mardi : l’agent cite un prix d’une liste périmée, « Romashka SARL » et « Romashka » deviennent deux clients distincts, et personne ne peut dire quel chiffre est vrai.

Le problème n’est presque jamais le modèle. Ce sont les données et le processus derrière. Voici la checklist que je déroule avec mes clients avant qu’un agent ne touche quoi que ce soit — dans l’ordre qui fonctionne réellement, avec les erreurs qui enterrent silencieusement ces projets.

Pourquoi les fichiers bruts sabotent un agent

Trois mécanismes, chacun fatal à lui seul :

1. Les contradictions deviennent des réponses assurées. Un agent ne sait pas que Tarifs-2025-FINAL-v3.xlsx remplace tarifs-anciens.xlsx. Il moyenne, devine ou en choisit un — et énonce le résultat avec une confiance totale. Les audits de tableurs menés depuis deux décennies (Ray Panko, Université d’Hawaï) trouvent systématiquement que ~88 % des tableurs d’entreprise contiennent des erreurs (synthèse de la recherche) ; un agent hérite de chacune, plus des conflits entre fichiers.
2. Sans clés, pas de jointures. Votre table de commandes indique le client « AK-114 », la feuille de paiements « Kamensky A. », l’onglet CRM « Andrey — gros ». Un humain résout cela de mémoire ; un agent non. Sans identifiants partagés, chaque recoupement est un pile ou face.
3. Le volume brûle de l’argent avant tout le reste. Un classeur de 40 onglets relu à chaque requête signifie que vos coûts évoluent avec la longueur de la conversation, pas avec la valeur livrée. (La mathématique des coûts au compteur des builders IA est détaillée dans Votre app Replit ou Lovable n’est pas prête pour la production.)

La préparation corrige les trois — et c’est en grande partie un travail que vous devriez faire de toute façon pour grandir au-delà des tableurs.

La checklist, dans l’ordre

1. Choisir un processus et mesurer sa base de référence

Un seul processus : la saisie de commandes, ou la validation de factures, ou les mises à jour de stock. Pas « les opérations ». Notez ce qu’il coûte aujourd’hui : heures par semaine, taux d’erreur, prix de la dernière erreur. Sans cette base de référence, impossible de prouver que l’agent a économisé quoi que ce soit — le projet meurt à la première question budgétaire.

2. Inventorier toutes les sources

Listez chaque fichier, onglet, outil et personne qui touche le processus. Incluez les sources fantômes : le tracker privé du responsable commercial, le groupe WhatsApp où les exceptions se décident vraiment, le tableau blanc. Tout ce que vous sautez ici réapparaîtra comme angle mort de l’agent.

3. Extraire les données de référence (les « spravotchniki »)

C’est le cœur de la préparation. Pour chaque liste sur laquelle tourne l’entreprise — clients, produits, prix, unités, statuts, entrepôts, centres de coûts — produisez exactement une version canonique :

• Un enregistrement par chose réelle. « Romashka SARL », « Romashka », « romashka (gros) » fusionnent en un client avec un identifiant.
• Un responsable nommé et une règle de mise à jour. Qui modifie la grille tarifaire, et qu’est-ce qui déclenche une modification ? Des données de référence sans propriétaire pourrissent en un trimestre.
• Des dates de validité là où la réalité change. Prix, taux de change, tarifs douaniers : gardez l’historique, mais l’agent doit toujours savoir quelle valeur est en vigueur.

4. Normaliser les formats

Des règles ennuyeuses, décisives :

Règle	Cassé	Corrigé
Les statuts sont une liste contrôlée	« payé ? », « à peu près payé », « PAYÉ !! »	paid / pending / overdue
Une ligne = un événement	Trois commandes fusionnées sur une ligne	Une ligne par commande
Dates dans un seul format	03.04.26, Avr-3, 2026/4/3	2026-04-03
Unités explicites	« 5 » (cartons ? pièces ? litres ?)	5 carton
Pas de mise-en-forme-comme-donnée	Cellules fusionnées, rouge = en retard, une feuille par mois	Lignes simples, colonne statut, colonne date

Les couleurs et les cellules fusionnées sont invisibles pour un agent — tout ce qu’elles encodent doit devenir une colonne.

5. Séparer les faits des références

Commandes, paiements, expéditions, tickets sont des événements : ils s’accumulent et ne sont jamais modifiés rétroactivement. Clients, produits, prix sont des références : ils changent. Les garder dans des tables séparées (plutôt qu’un méga-tableur) rend les réponses d’un agent cohérentes et vérifiables — c’est la même séparation qu’impose une vraie base de données (pourquoi Sheets cesse de passer à l’échelle).

6. Écrire le processus tel qu’il tourne vraiment

Pas la version de l’organigramme — la vraie. Pour chaque étape : qui la fait, ce qui la déclenche, ce qu’on y décide, quelles sont les exceptions, quel SLA s’applique. Deux demi-journées avec les personnes du processus suffisent généralement à la première version honnête. Chaque exception non écrite que vous omettez deviendra un incident futur du vendredi soir.

7. Attribuer rôles et permissions

Décidez maintenant qui peut voir les coûts, qui peut modifier les prix, qui peut approuver les remboursements. Dans les outils de chat, chacun voit tout ; dans un vrai système, cela devient un accès par rôles et une piste d’audit. Remettre à l’agent un modèle de permissions (même un simple tableau) prévient les fuites comme les zèles « serviables ».

8. Définir les garde-fous et la règle d’escalade

Ce que l’agent peut faire seul (répondre, rédiger, étiqueter, router) versus ce qui exige toujours un humain (envoyer de l’argent, contacter un client, modifier les données de référence, tout ce qui est sous le seuil de confiance). Définissez aussi le chemin d’erreur : face à des données absentes ou contradictoires, l’agent doit s’arrêter et demander — pas improviser.

9. Construire le jeu de tests

Prenez 20–50 cas historiques réels dont vous connaissez l’issue correcte, y compris les cas vicieux. Ce jeu est votre définition du « ça marche ». Après chaque changement de prompt ou de données, l’agent doit le réussir. Sans jeu de tests, « mieux » est indistinguable de « différent » — le mode de défaillance derrière la plupart des bûchers de tokens.

10. Préparer le paquet de remise

Ce que l’agent (ou l’ingénieur qui construit autour) reçoit : les fichiers de référence canoniques, le document de processus, la table de permissions, les règles de garde-fou, le jeu de tests et la base de KPI. Ce paquet — pas le prompt — est le véritable projet.

Les erreurs qui tuent ces projets

Erreur	Ce qui arrive	La correction
Remettre le dossier brut	L’agent répond depuis la mauvaise version	Étapes 3–5 d’abord, un processus à la fois
Données de référence sans propriétaire	Les listes divergent à nouveau en silence	Responsable nommé + règle de mise à jour, par écrit
Statuts en texte libre	L’agent ne peut ni compter, ni filtrer, ni escalader fiabilité	Vocabulaire contrôlé
Couleurs/cellules fusionnées comme données	L’agent est aveugle à la moitié du sens	Des colonnes, des lignes simples
Migrer tout l’historique le premier jour	Des mois de travail avant tout résultat	3–6 mois actifs, archiver le reste
Exceptions non écrites dans une seule tête	L’agent « tombe en panne au hasard »	Document de processus + inventaire des sources fantômes
Pas de jeu de tests	Prompts interminables, aucune preuve de progrès	20–50 cas avec réponses connues
Pas de base de KPI	ROI indémontrable ; budget coupé en route	Mesurer avant de construire

Ce qui change une fois les données préparées

Le même agent, sur le même modèle, se met à se comporter comme un autre système : il joint clients et paiements sans pile ou face, ses coûts cessent d’évoluer avec la taille des fichiers, ses réponses deviennent vérifiables contre le jeu de tests — et les erreurs restantes se corrigent en un seul endroit au lieu d’être traquées sur quarante onglets. C’est aussi exactement la préparation qui rend bon marché une migration ultérieure vers une vraie plateforme : la démo Sheets vers SQL le montre avec des chiffres réels.

La préparation fait la plus grande partie de la bataille — mais pas toute. L’article suivant couvre ce que la préparation des données ne peut pas réparer : pourquoi les équipes brûlent des centaines de prompts après avoir tout bien fait, et pourquoi la pièce manquante est une personne.

Sources et lectures complémentaires

• Introducing AgentKit — OpenAI — ce que les éditeurs livrent vraiment (et qui sont leurs « builders »)
• Raymond Panko, What We Know About Spreadsheet Errors — les audits à ~88 % de taux d’erreur
• When Google Sheets Stops Scaling — le plafond de volume derrière le mécanisme 3
• Google Sheets to SQL in One Transaction — où mène cette checklist : 1 686 enregistrements, 12 défauts trouvés, démo en direct