Applications métier CRUD

Depuis les années 1980, la grande majorité des applications métier ont adopté une conception interne similaire, à savoir CRUD, qui signifie Create / Read / Update / Delete (Créer / Lire / Mettre à jour / Supprimer). Cette conception reflète l’adoption d’une base de données relationnelle pour persister les données métier. La conception CRUD a survécu à plusieurs grandes avancées technologiques, des terminaux de console connectés aux mainframes aux applications mobiles connectées aux plateformes cloud. Comprendre la conception CRUD est important dans des domaines complexes - comme la supply chain - qui opèrent généralement au-dessus d’un paysage applicatif complet composé d’applications CRUD. Cette compréhension est essentielle pour naviguer correctement dans ce paysage, de la négociation avec les fournisseurs de logiciels à l’exploitation des données collectées par le biais de toutes ces applications.

Aperçu

Au début des années 1980, les bases de données relationnelles sont apparues comme l’approche dominante pour stocker et accéder aux données métier. À la fin des années 1990, les bases de données relationnelles open source émergentes ont encore renforcé cette pratique. De nos jours, la conception CRUD reflète l’approche la plus répandue pour concevoir une application métier sur une base de données relationnelle.

Une base de données, dans le sens relationnel, comprend une liste de tables. Chaque table comprend une liste de colonnes (également appelées champs). Chaque champ est associé à un type de données : nombre, texte, date, etc. Une table contient une liste de lignes (également appelées enregistrements). En règle générale, le nombre de colonnes est censé rester limité, quelques centaines au maximum, tandis que le nombre de lignes est illimité, pouvant atteindre des milliards.

Figure 1 : une table simple reflétant une liste de produits et leur situation en stock, illustrative de ce que l'on trouve généralement dans une base de données relationnelle.

En pratique, l’approche relationnelle nécessite plusieurs tables pour refléter quelque chose d’intéressant sur le plan métier (par exemple, les commandes d’achat). Ces “regroupements” de tables sont appelés des entités. Une entité reflète la compréhension globale de l’activité.

Figure 2 : une entité "panier d'achat" simple composée de deux tables. Cette entité reflète l'état du panier d'achat pour le visiteur d'un site de commerce électronique.

Comme mentionné ci-dessus, CRUD fait référence à Create (Créer), Read (Lire), Update (Mettre à jour) et Delete (Supprimer), les 4 opérations fondamentales à effectuer sur les tables d’une base de données relationnelle.

• Create : ajouter de nouvelles lignes à la table.
• Read : récupérer les lignes existantes de la table.
• Update : modifier les lignes existantes dans la table.
• Delete : supprimer les lignes existantes de la table.

Ces opérations sont effectuées à l’aide d’un langage de base de données dédié, presque toujours un dialecte SQL (Structured Query Language)¹ de nos jours.

La conception CRUD consiste à introduire des entités ainsi que leurs homologues d’interface utilisateur, généralement appelés “écrans”. Un écran, qui peut être une page web, présente généralement les 4 opérations pour l’entité concernée.

La grande majorité des applications métier “transactionnelles”, d’un simple suivi du temps à un Progiciel de Gestion Intégré (ERP) ou un CRM très complexe, adoptent une conception CRUD similaire en interne - un modèle de conception établi il y a plus de 4 décennies. Les applications simples ne comportent que quelques entités tandis que les applications complexes peuvent en comporter des milliers. Cependant, du simple au complexe, en termes de conception inhérente, c’est simplement plus de la même chose.

La diversité des interfaces utilisateur, telle qu’on la trouve dans les applications métier, peut être trompeuse dans le sens où il semble que les applications ont très peu en commun. Cependant, en pratique, la plupart des applications ont une conception interne presque identique alignée sur la perspective CRUD.

Applications CRUD dans la supply chain

Presque toutes les applications (exposées aux utilisateurs finaux) utilisées pour exploiter les entreprises et leurs processus sont des applications CRUD. En règle générale, si un logiciel d’entreprise bénéficie d’un acronyme de 3 lettres comme ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (etc.), alors il est presque invariablement implémenté en tant que CRUD. La principale exception à cette règle concerne les éditeurs de documents (par exemple, les logiciels de tableur), qui représentent un type de technologie logicielle totalement différent.

En interne, le service informatique utilise une large gamme de technologies qui ne sont pas CRUD : réseau, virtualisation, outils d’administration système, etc. Cependant, ces technologies ont tendance à être largement invisibles, ou du moins peu intrusives, pour les utilisateurs finaux.

Ces applications CRUD contiennent presque toutes les données transactionnelles historiques pertinentes qui peuvent être exploitées pour améliorer quantitativement la supply chain (par exemple, optimiser les niveaux de stock). Par conséquent, de nombreuses applications CRUD tentent², à un moment donné, de se diversifier vers des capacités analytiques (telles que la planification ou l’optimisation). Malheureusement, bien que le CRUD présente de nombreux avantages, il présente également de graves lacunes en ce qui concerne les capacités analytiques (voir “Les limites du CRUD” ci-dessous).

Les avantages du CRUD

Le CRUD a été l’approche privilégiée pour les applications métier depuis des décennies. D’un point de vue technologique, cette approche bénéficie de frameworks et d’outils open source complets dans toutes les principales piles logicielles. Par conséquent, le chemin technologique est exceptionnellement bien défini. De plus, le CRUD bénéficie également d’outils de développement de haute qualité et, par conséquent, la productivité tend à être élevée pour les ingénieurs logiciels impliqués dans le développement d’une application basée sur le CRUD.

D’un point de vue du personnel, il existe un large marché d’ingénieurs logiciels expérimentés dans le CRUD. De plus, le CRUD fait partie des parties les plus accessibles de l’ingénierie logicielle - en grande partie grâce à ses outils de développement de haute qualité. Par conséquent, le CRUD est extrêmement accessible même pour les ingénieurs logiciels juniors (et les moins talentueux des seniors). Comme les principes CRUD sous-jacents sont stables depuis des décennies, la transition vers une pile technologique plus récente peut également être réalisée relativement facilement - du moins par rapport à d’autres approches plus technologiques.

Enfin, d’un point de vue de la continuité des activités, le CRUD offre tous les avantages associés à sa base de données relationnelle sous-jacente. Par exemple, tant que la base de données est accessible à l’entreprise cliente, les données resteront accessibles ; cela est vrai même si le fournisseur d’origine de l’application CRUD n’est plus opérationnel/coopératif avec l’entreprise cliente. Même dans ce cas extrême, l’accessibilité des données peut être obtenue grâce à des efforts modestes de rétro-ingénierie.

Les limites du CRUD

Les applications CRUD sont confrontées à des limitations inhérentes liées à la manière dont elles exploitent internement la base de données relationnelle qui les sous-tend. Ces limitations ne peuvent pas être contournées sans renoncer fondamentalement aux avantages mêmes associés au CRUD. Ces limitations se situent dans deux grandes catégories : l’expressivité et les performances.

La limitation d’expressivité reflète le fait que les quatre actions (ou “verbes”) - créer, lire, mettre à jour et supprimer - ne peuvent pas capturer correctement un ensemble plus granulaire d’intentions. Par exemple, considérez une situation où un employé cherche à fusionner plusieurs entrées de fournisseurs qui ont été créées par erreur dans le SRM (Supplier Relationship Manager). Le verbe approprié pour cette opération serait fusionner. Cependant, la conception CRUD n’a pas ce verbe. En fait, cette capacité est invariablement mise en œuvre sous la forme d’un processus en deux étapes. Tout d’abord, mettre à jour toutes les lignes qui pointaient vers les entrées de fournisseurs à supprimer, afin qu’elles pointent maintenant vers celle à conserver. Ensuite, supprimer toutes les entrées de fournisseurs supplémentaires sauf une. Non seulement l’intention originale (la fusion) est perdue, mais la transformation est destructive en termes de données. De manière anecdotique, lorsque les applications CRUD avertissent leurs utilisateurs qu’ils s’apprêtent à apporter des modifications irréversibles aux données, il s’agit presque toujours d’une limitation du CRUD³ qui interfère avec l’expérience utilisateur.

La limitation de performance reflète le fait que toute opération de longue durée - c’est-à-dire toute opération qui lit plus qu’une infime fraction de la base de données - expose l’application CRUD au risque de devenir non réactive. En effet, pour une application CRUD, les utilisateurs finaux s’attendent à ce que la latence soit à peine perceptible pour presque toutes les opérations courantes. Par exemple, mettre à jour un niveau de stock dans le WMS (Warehouse Management System) devrait se faire en millisecondes (afin de maintenir des opérations fluides). Comme toutes les opérations données à l’application CRUD consomment des ressources informatiques de la même base de données relationnelle sous-jacente, presque toute opération non triviale expose ce cœur au risque d’être privé de ressources informatiques. De manière anecdotique, dans les grandes entreprises, les applications CRUD deviennent couramment non réactives pendant quelques secondes (voire quelques minutes) à la fois. Ces situations sont presque toujours causées par quelques opérations “lourdes” qui finissent par monopoliser les ressources informatiques pendant une courte durée, retardant ainsi toutes les autres opérations - y compris les opérations “légères”. Cette problématique explique pourquoi les opérations non triviales sont généralement séparées en travaux par lots qui s’exécutent la nuit. Cela explique également pourquoi les applications CRUD sont généralement peu performantes en matière d’analyse, étant donné que les charges de travail analytiques sont impraticables à exécuter uniquement en dehors des heures de bureau.

Les variantes modernes du CRUD

Au cours des dernières décennies, les logiciels d’entreprise ont connu des évolutions substantielles. Dans les années 1990, la plupart des applications sont passées des terminaux de console aux interfaces utilisateur de bureau. Dans les années 2000, la plupart des applications sont passées des interfaces utilisateur de bureau aux interfaces utilisateur web. Au cours de la dernière décennie environ, la plupart des applications ont basculé vers le SaaS (logiciel en tant que service) et se sont migrées vers le cloud computing dans le processus. Cependant, la conception CRUD est restée largement inchangée par ces évolutions.

La transition de la location unique à la location multiple⁴ a contraint les éditeurs de logiciels à contrôler l’accès aux données des entités via des API (interfaces de programmation d’applications). En effet, un accès direct à la base de données, même en lecture seule, crée la possibilité d’épuiser les ressources informatiques du cœur transactionnel avec seulement un petit nombre de requêtes lourdes. L’API atténue ce type de problèmes. Le fait de contrôler l’accès aux données de l’application via une API annule également certains des avantages du CRUD, du moins du point de vue de l’entreprise cliente. Extraire de manière fiable une grande quantité de données à partir d’une API nécessite généralement plus d’efforts que de composer une série comparable de requêtes SQL. De plus, l’API peut être incomplète - ne pas exposer les données qui existent dans l’application - même si la base de données directe devrait avoir accordé un accès complet aux données par conception.

L’évolution principale du CRUD se trouve dans les outils. Au cours des années 2010, une grande variété d’écosystèmes open source de haute qualité ont émergé pour soutenir le développement d’applications CRUD. Ces écosystèmes ont largement standardisé le développement d’applications CRUD, réduisant ainsi considérablement les compétences nécessaires pour les développer et les frictions associées au processus de développement.

Dynamique des fournisseurs

Le coût de développement d’une application CRUD est largement déterminé par le nombre d’entités. Plus le nombre d’entités est élevé, plus il faut développer, documenter et maintenir d’écrans. Ainsi, le chemin naturel pour un éditeur de logiciels promouvant une application CRUD consiste à commencer par un nombre limité d’entités, puis à en ajouter progressivement davantage.

L’ajout d’entités débloque de nouvelles fonctionnalités et donne à l’éditeur l’opportunité d’augmenter ses prix, reflétant la valeur ajoutée supplémentaire créée pour l’entreprise cliente. De plus, des modules⁵, c’est-à-dire des regroupements d’entités liées à l’activité, sont fréquemment introduits en tant que mécanisme de tarification pour facturer davantage (en fonction de l’étendue de l’utilisation du produit logiciel).

En conséquence, les applications CRUD ont tendance à devenir de plus en plus complexes avec le temps, mais aussi de moins en moins pertinentes. En effet, à mesure que de nouvelles entités sont ajoutées pour servir l’intérêt de l’ensemble de la base de clients, bon nombre (voire la plupart) des entités nouvellement introduites ne sont pas pertinentes pour une entreprise cliente individuelle. Ces entités “mortes” - du point de vue de l’entreprise cliente - représentent une complexité accidentelle croissante qui pollue le CRUD.

Les applications CRUD vendues en tant que SaaS ont tendance à devenir plus chères à mesure qu’elles gagnent en capacité et en notoriété. Cependant, comme il y a très peu de barrières à l’entrée⁶, de nouveaux fournisseurs émergent fréquemment, chacun se concentrant sur des cas d’utilisation à des niveaux de prix beaucoup plus bas - et le cycle se répète à l’infini.

La vision de Lokad

Beaucoup, voire la plupart, des grandes entreprises sous-estiment l’étendue de la banalisation des applications CRUD. Pour la plupart des éditeurs de logiciels d’entreprise qui les vendent, le coût de développement n’est qu’une infime fraction des dépenses totales de l’entreprise, bien loin des coûts liés à la commercialisation et à la vente des applications elles-mêmes. En particulier, les éditeurs développant des applications CRUD délocalisent fréquemment leurs équipes d’ingénierie dans des pays à faible coût, car l’approche CRUD (étant donné son accessibilité globale) peut tolérer une main-d’œuvre d’ingénierie moins talentueuse - et moins chère.

Il y a très peu de raisons de nos jours de payer des sommes importantes pour des applications CRUD. En règle générale, toute application CRUD qui coûte plus de 250 000 USD par an est un sérieux candidat pour un remplacement par un logiciel interne. Toute application CRUD qui coûte plus de 2,5 millions de dollars par an devrait, presque sans exception, être remplacée par un logiciel interne (éventuellement à partir d’une base open-source préexistante et en la personnalisant).

Les éditeurs de logiciels d’entreprise qui vendent des applications CRUD sont parfaitement conscients de ce problème (et cela fait longtemps). Ainsi, il est tentant pour le fournisseur d’ajouter des fonctionnalités/applications/éléments non-CRUD dans la solution et d’essayer de convaincre les clients (a) que ces éléments sont importants et (b) que ces éléments représentent une sorte de “sauce secrète” que le client ne pourra pas reproduire. Cependant, cette approche réussit presque jamais, principalement parce que le fournisseur n’a pas l’ADN d’ingénierie approprié⁷. À titre de preuve anecdotique, presque tous les ERP notables et établis disposent de capacités étendues de prévision et de planification, dont la plupart sont très peu utilisées en raison de leur mauvaise performance dans ces tâches.

Lokad est un éditeur de logiciels d’entreprise spécialisé dans l’optimisation prédictive de la supply chain. Notre technologie a été conçue pour exploiter les données transactionnelles historiques - celles qui peuvent être extraites des applications CRUD qui soutiennent les opérations quotidiennes d’une entreprise. Cependant, Lokad lui-même n’est pas une application CRUD. Notre environnement de production ne comprend même pas de base de données relationnelle. Alors que le CRUD est une réponse technologique valide pour la gestion des flux de travail transactionnels d’une entreprise, il n’a aucune pertinence pour la modélisation prédictive ou l’optimisation mathématique d’une supply chain.

Notes