Deux camps s’affrontent encore autour des microservices data et du monolithe BI. D’un côté, le monolithe : un entrepôt, des modèles, des rapports. De l’autre, la dispersion : chaque domaine expose ses APIs. Les deux ont raison sur une partie du problème, et tort dès qu’ils deviennent une idéologie.
Le consommateur comme critère
Le BI central reste pertinent pour le reporting transverse, la conformité, l’historique long. Il est moins adapté quand une application ou un agent a besoin d’une lecture métier fraîche, avec droits fins et latence courte. Inversement, une jungle d’APIs sans contrat ni gouvernance recrée le chaos que l’entrepôt devait résoudre. Une couche d’APIs data sert justement à cadrer cette exposition.
Le critère utile est le consommateur. Rapport mensuel : entrepôt. Action opérationnelle ou agent : API de domaine avec sémantique claire. Les deux coexistent dans les SI sains. Ce qui doit être unique, ce n’est pas le stockage. C’est le sens des objets métier. Sans ce sens partagé, chaque camp construit sa vérité locale, et les agents s’égarent.
Capacité d’équipe et calendrier
Le calendrier compte aussi. Un entrepôt peut absorber une vague de reporting en quelques mois. Une maille fine d’APIs demande une discipline continue de contrats et de versions. Choisir le grain sans regarder la capacité de l’équipe à le tenir est une erreur classique. L’architecture idéale sur papier devient vite une dette si personne ne l’opère.
Si le débat interne oppose tout dans le DWH à tout en microservices, le recentrer sur les cas d’usage des six prochains mois est souvent plus productif. On découvre alors qu’il ne fallait pas choisir un camp. Il fallait choisir, pour chaque consommation, le chemin le plus honnête. Pour cadrer cet arbitrage, voir aussi nos solutions.
