Le système de record devrait être local
Je suis venu à penser que, pour la supply chain, la plupart des entreprises devraient cesser d’acheter des systèmes de record généraux et commencer à les développer localement. Je parle du logiciel qui enregistre les commandes, les réceptions, les mouvements de stocks, les factures, les approbations, et les conséquences administratives des opérations courantes. Ces systèmes sont critiques, mais leur valeur est limitée. Ce sont des registres dotés de flux de travail. Le marché les évalue, les présente et les régit comme s’ils étaient les joyaux de la couronne de l’entreprise. Cette erreur est devenue très chère.
Dans Introduction à la Supply Chain, notamment les chapitres 5 et 6, j’ai tracé une ligne de démarcation entre le logiciel qui conserve la trace papier et le logiciel qui prend des décisions. Cette distinction importe ici. Une fois que nous examinons un système de record sans tout le théâtre habituel, une grande partie du mysticisme disparaît. Un système de record devrait être fiable, vérifiable et plutôt ennuyeux. Il ne devrait pas prétendre penser. Il devrait se contenter de mémoriser des faits, d’appliquer quelques flux de travail et de rester en retrait.
La taxe cachée des registres packagés
Un système de record atteint rapidement sa maturité commerciale. Dès qu’il peut gérer fidèlement les achats, les ventes, les stocks, la facturation et quelques flux de travail adjacents, la valeur supplémentaire de l’élargir est minime. Les fournisseurs le savent parfaitement. Leur réponse est restée la même pendant des décennies : ajouter une autre entité, un autre écran, un autre module, une autre page de configuration. Vendre le prochain incrément à la base installée. Avec le temps, le produit devient le sédiment d’innombrables demandes de clients, beaucoup sensées isolément et absurdes dans l’ensemble. Le résultat est un mastodonte de fonctionnalités dont la complexité ne cesse de croître, même si la tâche sous-jacente a à peine changé.
La littérature académique décrit le même problème avec des termes plus mesurés depuis des années. Strong et Volkoff ont observé que les systèmes d’entreprise packagés sont conçus pour des exigences génériques plutôt que spécifiques et tendent donc à mal s’adapter à toute organisation concrète. Une étude plus récente sur la personnalisation des ERP explicite le compromis : la personnalisation peut améliorer la fonctionnalité et la satisfaction des utilisateurs, mais elle augmente également le coût de mise en œuvre, la complexité et les dépenses des mises à niveau ultérieures. Une revue de 2025 sur les ERP inadaptés aboutit à une conclusion tout aussi sobre : les taux d’échec de mise en œuvre restent élevés, le décalage entre les processus standardisés et les flux de travail locaux persiste, et aucune pratique industrielle largement adoptée n’a émergé pour résoudre ces discordances de manière nette.
Cette taxe ne se limite pas aux frais de licence. Le benchmark ERP de Panorama de 2025 indique un coût médian de projet de 450,000 USD et un délai médian de neuf mois. Parmi les projets ayant dépassé le budget, la raison la plus fréquente était le besoin inattendu d’une technologie supplémentaire. Parmi ceux qui ont pris du retard, les problèmes de données étaient le principal coupable. Le même rapport note que de nombreuses implémentations ERP échouent encore à éliminer les silos organisationnels. C’est le schéma que je constate sans cesse : la suite n’abolit pas la complexité, elle la redirige vers l’intégration, la migration, la gouvernance et des solutions de contournement élaborées.
Les modèles de données sous-jacents racontent la même histoire. La documentation de Microsoft pour Dynamics explique qu’un concept commercial simple, tel qu’un client, peut être dispersé à travers plusieurs tables normalisées, raison pour laquelle les entités de données existent en tant qu’abstractions dénormalisées. La documentation de JD Edwards d’Oracle expose de longs catalogues de tables par type et par module. ERPRef, un catalogue de schémas tiers, recense 1,687 tables pour SAP Business One 9.0 et 5,097 pour JD Edwards 9.20 ; dans ce même catalogue, la table des factures A/R dans SAP Business One 9.3 est indiquée avec 424 colonnes. Une entreprise donnée n’utilisera qu’une infime partie de cette étendue, et pourtant elle paie pour cette étendue en termes d’autorisations, de cartographies, d’intégrations, de formations et de mises à niveau.
Il existe une deuxième taxe, et c’est souvent la plus dommageable. La vision de l’entreprise fondée sur l’attention de William Ocasio part d’une observation simple : ce que font les entreprises dépend de la manière dont l’attention des décideurs est canalisée. Un système de record tentaculaire consomme cette attention aussi sûrement qu’il consomme de l’argent. Les années consacrées aux implémentations, aux nettoyages, aux migrations, aux refontes, aux ajouts complémentaires et aux mises à niveau sont des années pendant lesquelles la haute direction est absorbée par la mécanique de l’infrastructure administrative. J’ai soutenu ailleurs que, lorsque les registres et les rapports consomment la majeure partie du budget logiciel, ils absorbent également la majeure partie de la capacité exécutive, laissant peu de place pour le logiciel qui pourrait réellement améliorer les décisions.
Pourquoi le sur-mesure a cessé d’être difficile
Le fait remarquable est que l’argument technique en faveur des systèmes de record sur mesure a cessé d’être exotique il y a bien longtemps. PostgreSQL bénéficie de près de quarante ans de développement actif et est conforme aux normes ACID depuis 2001. ASP.NET Core est gratuit, open source et multiplateforme. Entity Framework Core prend en charge le suivi des modifications, les mises à jour et les migrations de schéma sur plusieurs bases de données. Django est livré avec des protections intégrées contre les attaques web courantes. Lorsque la plomberie du logiciel transactionnel a atteint ce niveau de maturité, construire un registre interne restreint n’est plus un acte de bravoure.
Il y a même un détail révélateur dans la documentation de Django. Son interface d’administration automatique est recommandée pour l’outil de gestion interne d’une organisation, et non pour une interface publique. Cette petite remarque résume toute l’affaire. L’industrie a standardisé si complètement l’ossature back-office des logiciels CRUD que les principaux frameworks l’intègrent désormais dès la sortie de la boîte. Ce qui reste difficile, ce n’est pas la plomberie. Ce qui reste difficile, c’est de décider quelles entités, quels états et quels flux de travail importent réellement pour votre entreprise et lesquels sont là seulement parce qu’un fournisseur a passé vingt ans à collecter des particularités d’un segment de marché.
C’est ici que le sur-mesure l’emporte de manière décisive. L’avantage ne réside pas dans une virtuosité du code. L’avantage est l’exactitude sémantique. Les entités peuvent correspondre à l’entreprise telle qu’elle fonctionne réellement : sa hiérarchie de produits, ses exceptions d’achat, ses statuts de réception, ses règles d’approbation, ses motifs de retour, ses blocages qualité, ses distinctions particulières mais utiles que toute suite générique ne devrait pas être censée comprendre. Un petit code local peut rester intelligible. Plus important encore, l’entreprise conserve la propriété du savoir opérationnel incarné dans ce code. Le logiciel reflète l’activité; l’entreprise n’a plus à hériter des compromis accumulés de toute la base de clients d’un fournisseur.
Ce que les agents de codage ont changé
Ce qui a changé en 2025, ce n’est ni la base de données, ni le navigateur, ni la pile web. Ce qui a changé, c’est le coût de production du code. En janvier 2025, Anthropic a rapporté 49 percent sur SWE-bench Verified pour un agent Claude 3.5 Sonnet amélioré. En août, Claude Opus 4.1 a atteint 74,5 percent. L’équipe SWE-bench a ensuite noté que le mini-SWE-agent atteignait 65 percent sur le même sous-ensemble vérifié dans une configuration minimale. OpenAI, pour sa part, a lancé Codex en tant qu’agent logiciel cloud capable de travailler sur de nombreuses tâches en parallèle, d’exécuter des tests et des linters dans des environnements isolés, et de proposer des modifications pour révision ; dans une expérience produit interne distincte, OpenAI affirme que Codex a écrit l’intégralité d’une base de code d’un million de lignes, construite en environ un dixième du temps qu’aurait requis une programmation manuelle.
Cela ne signifie pas que les agents rendent chaque ingénieur plus rapide sur chaque base de code. L’essai randomisé de METR sur des développeurs open-source expérimentés a révélé que, début 2025, les outils d’IA les ralentissaient de 19 percent lorsqu’ils travaillaient sur leurs propres dépôts. Je prends ce résultat au sérieux. Pourtant, il ne décrit pas le même problème. Maintenir une base de code publique mature avec des standards exigeants et des années de contexte tacite n’est pas la même tâche que de concevoir un flux de travail de réception, un portail fournisseur, un back office d’ajustement de stocks ou une interface de retours pour une équipe interne. Pour ces derniers, les exigences sont locales, les critères d’acceptation sont concrets et l’architecture est ordinaire. Le travail sur l’horizon temporel mené séparément par METR rapporte également que la durée des tâches logicielles que les agents de pointe peuvent accomplir avec une fiabilité de 50 percent a doublé environ tous les sept mois. C’est exactement le type de tendance qui importe lorsque le travail est restreint et bien défini.
C’est pourquoi même un fabricant, distributeur ou détaillant ordinaire peut désormais posséder de manière sensée une bien plus grande part de son logiciel transactionnel qu’auparavant. Une telle entreprise n’a pas besoin de devenir un fournisseur de logiciels. Il lui faut un responsable de processus qui connaît l’activité, un chef techniquement compétent, un petit code, une suite de tests et la discipline de maintenir le périmètre restreint. Les agents de codage réduisent la quantité de mise en œuvre manuelle nécessaire pour les parties ennuyeuses, qui représentent d’ailleurs la majorité des éléments dans les systèmes de record. Pendant ce temps, la pile open-source mature s’occupe du reste. La combinaison est puissante précisément parce que les systèmes de record sont si peu attrayants. Ils se composent principalement de formulaires, de tables, de validations, d’autorisations, de flux de travail et d’intégrations. C’est là que les outils sont les plus performants.
J’épargnerais toutefois les domaines dans lesquels la principale valeur du fournisseur réside dans le suivi des changements réglementaires. Ce sont de vraies exceptions. En dehors de ceux-ci, surtout dans la supply chain, la situation par défaut devrait s’inverser. Pour les flux d’achat, la réception, les retours, les blocages qualité, la collaboration avec les fournisseurs, la gestion des données principales et d’autres domaines transactionnels similaires, les logiciels packagés généraux sont devenus le moyen coûteux d’obtenir un ajustement médiocre. L’alternative sur-mesure n’est plus réservée aux entreprises technologiques. Elle est désormais à la portée des entreprises ordinaires, à condition qu’elles soient prêtes à posséder une quantité modeste de code et à refuser la tentation de transformer cette base de code en une grande plateforme.
L’argument n’est plus sentimental et il n’est plus futuriste. Les registres packagés généraux sont génériques par construction, inadaptés par habitude, et inflationnistes tant en termes de coût que d’attention. Les outils pour construire des remplaçants restreints existent depuis des années. Les agents de codage ont désormais compressé la dernière partie qui empêchait de nombreuses entreprises d’agir, à savoir la quantité pure de codage routinier. Pour les systèmes de record de la supply chain, la charge de la preuve s’est inversée. Une entreprise devrait commencer par se demander pourquoi ce système devrait être acheté en premier lieu.
