# 78 onglets géraient une entreprise, sans mode d’emploi écrit > Un grossiste est passé d’un classeur Excel partagé à un vrai système de commandes, sans perdre les règles qui n’existaient que dans ses cellules. Source: https://redbumerang.com/fr/etudes-de-cas/gestion-commandes/ IA des processus / distribution de gros Un classeur, un onglet par date de livraison, aucune formule. L’entreprise fonctionnait correctement chaque jour selon des règles inscrites dans l’agencement des cellules et dans la mémoire de quelqu’un. *Client anonymisé. Mesures fondées sur le classeur, le résultat de migration et le modèle de données, 6 septembre 2026.* ## Le problème Un seul fichier Excel faisait tourner une entreprise de distribution de gros, et les règles qu’il appliquait n’existaient nulle part ailleurs. Un classeur. Soixante-dix-huit onglets, un par date de livraison. Sous chaque date, les clients étaient regroupés par tronçon de livraison ; sous chaque client, la commande du jour était saisie en texte libre abrégé : 2x pečen pršut polovice, 1# panceta narezek 100g. La planification vivait dans les mêmes cellules que les commandes, sous forme de notes au lecteur : na 14 dni, toutes les deux semaines. klicati ob petkih, appeler le vendredi. klicano, appelé. poslan SMS. dostava JUTRI. Il n’y avait aucune formule. Pas une seule sur les quatre-vingts feuilles, et six commentaires de cellule dans tout le classeur. C’était toute la documentation. Cela compte plus qu’il n’y paraît. Une règle dans une formule est au moins écrite : on peut l’ouvrir et la lire, aussi péniblement que ce soit. Ces règles n’étaient écrites nulle part. Elles vivaient dans la mise en page des feuilles et dans les habitudes de leurs utilisateurs. L’entreprise fonctionnait correctement chaque jour grâce à un savoir qui n’existait que dans l’agencement des cellules et dans la mémoire de quelqu’un. Et comme il s’agissait d’un seul fichier partagé, une seule personne à la fois pouvait le modifier sans risque. Il gagnait aussi un onglet chaque jour ouvré. Soixante-dix-huit n’était que le stade atteint. À ce rythme, le fichier aurait contenu plus de trois cents feuilles à la fin de l’année : un classeur unique que personne ne pourrait ouvrir, parcourir ou comprendre, se dégradant à cadence fixe sans point d’arrêt naturel. Les conséquences pratiques étaient celles qui coûtaient de l’argent : - Personne ne pouvait répondre à « qui appelons-nous aujourd’hui ? » Chaque client avait un rythme d’appel réel, mais il n’existait que sous forme de régularité dans les commandes passées. Il n’avait jamais été écrit, il fallait donc s’en souvenir. - Aucune vue d’un client sur plusieurs jours. Chaque feuille représentait un jour ; l’historique d’un client était éparpillé sur soixante-dix-huit feuilles. - Aucune trace de qui avait changé quoi, et aucun moyen de travailler à deux en même temps. ## Ce que Red Bumerang a construit Le classeur a été lu de bout en bout, ses règles reconstituées, et le résultat reconstruit sous forme d’application utilisable par plusieurs personnes à la fois. Pas un tableur avec une meilleure interface. Un système doté de vrais référentiels clients et produits, de trois rôles, de statuts de commande et d’appel, de la gestion des jours fériés, de l’impression, de l’analytique et d’une trace d’audit pour chaque modification. 363 clients. 111 produits. 1 581 commandes. 3 888 lignes de commande. Le tout reconstitué à partir d’un texte libre qui n’avait jamais été structuré. La partie qui répond à la question restée sans réponse Le rythme d’appel a été reconstitué à partir de l’historique des commandes. Chaque client en avait un. Aucun n’était enregistré. Les commandes passées de chaque client ont donc été analysées pour détecter une régularité, qui est devenue un calendrier lorsqu’elle était assez nette. Sur 335 clients ayant un historique de commandes, 174 ont reçu un calendrier d’appels récurrent. 153 avaient trop peu de commandes pour conclure, et 8 ne présentaient aucune régularité : c’est signalé tel quel plutôt que remplacé par une supposition. L’application construit désormais la liste d’appels quotidienne à partir de ces calendriers, la décale autour des jours fériés et permet au personnel d’écarter un appel une seule fois sans rompre la récurrence. « Qui appelons-nous aujourd’hui ? » est désormais un écran plutôt qu’un souvenir. La discipline imposée par le système Les commandes étaient de la prose. Ce sont désormais des articles. Rien dans le classeur ne contrôlait la saisie. Une ligne de commande était ce que l’opérateur avait envie d’écrire ce jour-là : le même produit décrit de trois façons par trois personnes, sans code commun. Le système reconstruit n’accepte pas la prose. Chaque ligne est saisie dans le véritable catalogue produits au moyen d’un sélecteur interrogeable, avec une découpe et une conversion pièces-kilogrammes associées. Une commande en pièces et une commande en kilos correspondent ainsi au même enregistrement. Cette contrainte fait plus qu’il n’y paraît. Une entreprise ne peut pas analyser ce qu’elle n’a pas standardisé, et aucun volume de rapports bâtis sur du texte libre n’aurait produit une réponse exploitable. Discipliner la saisie était la condition préalable à tout ce qui suivait : liste d’appels, analytique et vue par produit. Les 21,2 % que nous avons délibérément laissés au contrôle humain L’analyseur lit des abréviations comme 8x kulen narezek 500g 4kg et les transforme en ligne structurée : produit, quantité, découpe et conversion entre pièces et kilogrammes. Il a signalé 823 lignes sur 3 888, soit 21,2 %, comme nécessitant un examen humain. C’est un choix de conception délibéré, pas une lacune. Les abréviations slovènes de commande sont réellement ambiguës : kom et kos désignent chacun à la fois une unité de comptage et une découpe. Un analyseur qui trancherait en silence se tromperait sur une fraction inconnue du carnet de commandes actif, sans que personne sache laquelle. Il signale donc plutôt que de deviner, et chaque ligne conserve son texte original. Un système qui indique quel cinquième des données vérifier vaut bien plus qu’un autre qui masque son incertitude. ## Où se trouve réellement l’IA Aucune IA n’intervient à l’inférence. Tout s’est joué dans la construction. Le système en fonctionnement est déterministe : analyse selon des règles avec score de confiance, détecteur de calendrier fondé sur des histogrammes à seuils fixes, code applicatif ordinaire. Rien n’appelle de modèle. L’IA a fait le travail d’archéologie. Elle a lu un classeur non documenté et un tarif, en a déduit le domaine et le modèle de données, écrit les règles de l’analyseur, conçu la logique de déduction des calendriers et construit l’application. C’est la version honnête, et la plus forte : l’IA a reconstitué les règles selon lesquelles une entreprise fonctionnait sans les avoir écrites, puis construit le système qui les applique. Le résultat fonctionne de manière prévisible, chaque jour, sans modèle dans la boucle. ## Les règles que personne n’avait écrites Deux exemples apparus uniquement parce que le fichier entier a été lu : - Le même produit existait sous deux codes article, un code à cinq chiffres et une version à six chiffres préfixée par neuf pour la même chose. Lire une seule feuille aurait fait voir deux produits. Il fallait les fusionner en un seul. - Deux magasins d’une même enseigne partageaient un seul code client et devaient être distingués par leur nom et un sous-code, sans quoi deux relations de livraison distinctes se confondaient. Rien de tout cela n’était écrit. Les personnes qui savaient appliquaient pourtant les deux règles correctement chaque jour. ## Méthode Ce que comptent les chiffres. Les 78 feuilles datées sont le contenu du classeur, de février à mai 2026 (80 feuilles au total, dont deux sans commandes). Les nombres de clients, produits, commandes et lignes sont le résultat d’un seul passage de migration déterministe sur ce classeur. 21,2 % est la part des lignes de commande signalées par l’analyseur pour examen. Les chiffres de calendrier couvrent les 335 clients ayant un historique de commandes. Ce qui n’est pas revendiqué. Aucun gain de temps, coût ou retour chiffré n’est publié, car aucun n’a été mesuré. Il n’existe aucune étude du processus manuel antérieure à la reconstruction. Selon le propriétaire, la construction a pris quelques jours ; aucun chiffre précis n’est donné, car l’historique des versions ne permet pas de l’étayer. Périmètre. Un client, un classeur, la Slovénie. En production et utilisé chaque jour. --- ## Venez avec un processus ou un marché. Chaque système présenté ici a commencé par une conversation sur un travail qui se faisait déjà : son fonctionnement réel, ses postes les plus coûteux et l’ordre qui le sous-tend. C’est l’objet du premier rendez-vous.