Le maillage applicatif · Une nouvelle fondation

Quatre défis,
un seul problème d'architecture

Les plateformes d'entreprise doivent désormais servir un éventail de consommateurs bien plus large. Les données ne sont plus consultées principalement par des personnes utilisant des rapports et des applications. Elles sont aussi consommées en continu par des services, des modèles, des agents et des workflows automatisés, chacun avec ses propres schémas d'accès et exigences de performance.

Une nouvelle fondation pour les applications d'entreprise

Quatre problèmes qui n'en font qu'un

Ce basculement crée quatre défis étroitement liés. Les entreprises doivent rendre les données temps réel et historiques accessibles selon un modèle d'exploitation cohérent. Elles doivent trouver un moyen durable de faire passer les applications dotées d'IA du prototype à la production. Elles doivent étendre la gouvernance au-delà des utilisateurs et des bases de données, jusqu'aux applications, aux services et aux agents autonomes. Et elles doivent réduire la distance entre les données, les décisions et l'exécution.

Ces sujets sont le plus souvent traités comme des initiatives technologiques distinctes. Une équipe construit un maillage de données, une autre lance un programme de développement d'IA, une autre met en place des contrôles de gouvernance, et chaque métier continue de bâtir ses applications autour de ses propres systèmes.

Résoudre chaque problème indépendamment tend à créer de la complexité supplémentaire là où les solutions se rejoignent. Le besoin sous-jacent est plus large : les entreprises ont besoin d'une fondation commune permettant d'accéder aux données, d'appliquer la logique, de construire les applications et de gouverner les actions.

Défi 01

Relier les données temps réel et historiques

Schéma : des consommateurs accèdent aux sources streaming, opérationnelles, entrepôts et référentiels via une couche d'accès unique

Les patrimoines de données se sont constitués au fil de générations technologiques successives : transactions dans des bases relationnelles, événements par des plateformes de streaming, données clients et produits dans les systèmes opérationnels, historique dans des entrepôts et des lacs de données.

Chacun est adapté à sa finalité d'origine. Le problème apparaît lorsqu'un même processus métier en sollicite plusieurs à la fois. Une seule décision peut exiger des événements en direct, un état intrajournalier, un historique long et des données de référence. Lorsque chaque consommateur intègre ces sources de son côté, l'entreprise accumule des connexions point à point, des transformations dupliquées et des contrôles d'accès incohérents.

La réponse n'est pas un référentiel central unique ; les systèmes sources doivent souvent rester la référence. Le besoin est de virtualiser l'accès à l'ensemble du patrimoine existant, afin que les consommateurs interrogent les données via des interfaces stables, pendant que la plateforme gère la connectivité, la normalisation, les droits d'accès et la mise en cache. Les données temps réel et historiques restent physiquement distribuées, mais deviennent opérationnellement connectées.

Défi 02

Industrialiser les applications agentiques

Schéma : l'écart entre un prototype fonctionnel et une application de production gouvernée

Une équipe passe désormais d'une idée à une interface fonctionnelle en quelques jours. Mais la rapidité du prototypage masque la différence entre un logiciel qui démontre un concept et un logiciel auquel on peut se fier en production.

Une application de production ne se contente pas d'exécuter sa logique centrale. Elle gère l'identité, les permissions, l'état, la concurrence, les erreurs et des données changeantes, et doit être testée, déployée, supervisée et mise à niveau. Le code généré par l'IA ne supprime pas ces responsabilités ; il les augmente souvent.

L'approche durable n'est pas de générer chaque couche, mais de fournir les capacités récurrentes au sein de la plateforme, pour que développeurs et agents se concentrent sur la logique propre au métier. L'objectif n'est pas d'avoir des applications plus rapides, mais un chemin plus court entre le prototype et un logiciel que l'on peut gouverner et exploiter.

Défi 03

Gouverner les données à l'échelle de l'entreprise

Schéma : droits d'accès, traçabilité, application des politiques et audit appliqués sur tout le chemin de la donnée

La gouvernance traditionnelle s'est concentrée sur les utilisateurs, les bases de données et le reporting : accès selon l'identité et le rôle, avec catalogues, traçabilité et audit pour consigner l'usage de l'information.

Ce modèle est mis à mal à mesure que les consommateurs se multiplient. Des applications accèdent à plusieurs sources pour le compte d'un utilisateur, des services tournent en continu sans intervention humaine, et des agents sélectionnent des outils dynamiquement. La gouvernance ne peut plus reposer sur le périmètre de chaque base et doit s'étendre à tout le chemin par lequel la donnée est demandée, transformée et exploitée.

La plateforme doit savoir qui ou quoi émet une requête, ce à quoi il peut accéder et où ses résultats peuvent aller, de façon identique que le consommateur soit une personne, une application ou un agent d'IA. Placez les droits d'accès, la traçabilité, l'application des politiques et l'audit dans l'infrastructure : l'environnement peut évoluer sans perte de maîtrise.

Défi 04

Rapprocher données, logique et exécution

Schéma : détecter, évaluer, approuver et agir dans un même flux opérationnel

De nombreux processus d'entreprise suivent encore un chemin fragmenté de l'observation à l'action : donnée captée dans un système opérationnel, copiée dans une plateforme analytique, présentée dans un rapport, interprétée par un utilisateur, saisie comme décision ailleurs, puis envoyée à un système d'exécution.

Chaque système peut parfaitement remplir son rôle, et pourtant le processus dans son ensemble reste lent et fragile. La donnée est périmée au moment de l'analyse, le contexte se perd d'une application à l'autre, et chaque transfert crée une intégration de plus à sécuriser. Un agent capable d'analyser l'information mais incapable d'atteindre l'état courant, d'invoquer une logique gouvernée ou de déclencher une action approuvée reste déconnecté du résultat.

L'objectif n'est pas de fondre les systèmes spécialisés en une seule application ; chacun conserve sa finalité. Ils devraient en revanche partager un même flux opérationnel, assez proches pour qu'un signal puisse être détecté, évalué, approuvé et exécuté sans transferts fragiles.

Le maillage applicatif

Une fondation commune, pas quatre programmes séparés

Lus séparément, ce sont quatre feuilles de route qui se disputent le même budget et les mêmes ingénieurs. Lus ensemble, ils décrivent un seul besoin d'architecture : une couche par laquelle on accède aux données, on applique la logique, on construit les applications et on gouverne les actions.

Cette couche, c'est le maillage applicatif.

Poursuivre la lecture

Ces problèmes ont déjà été résolus, sur d'autres marchés.

Les plateformes de commerce et les moteurs de jeu ont chacun répondu à une partie de la même question d'architecture, à grande échelle et en production. Découvrez lesquelles de leurs approches ont tenu dans la durée, et ce que le maillage applicatif retient de chacune.

Des modèles éprouvés sur d'autres marchés Découvrir le maillage applicatif