KabeenKabeenIT Playbook
Découvrir Kabeen
05 · Faire évoluer

05.01 · Faire évoluer

Vers un SI plateformisé

Plateformiser un SI ne veut pas dire tout centraliser. Cela veut dire identifier les briques mutualisables qui rendent le reste plus rapide — et résister à la tentation de mutualiser ce qui ne devrait pas l’être.

Par L’équipe Kabeen·12 min de lecture·Mis à jour le 15 mai 2026

La promesse plateforme, la réalité plateforme

La plateformisation est l’une des promesses les plus puissantes — et les plus mal exécutées — de la décennie 2020. La promesse : remplacer le patchwork applicatif par un socle commun (identité, données, intégration, observabilité) qui rend chaque nouveau cas d’usage plus rapide à délivrer. La réalité, observée dans la majorité des projets engagés : on construit la plateforme pendant trois ans, on ne la livre jamais complètement, et les équipes finissent par contourner pour avancer.

3,5 ans
Durée médiane d’un programme de plateformisation avant son premier vrai bénéfice mesurable.
Estimation Kabeen, panel ETI
40 %
Programmes de plateformisation arrêtés ou redirigés avant complétion.
McKinsey, Platform Strategy 2023
× 3
Vitesse de livraison des cas d’usage post-plateforme, dans les programmes réussis.
McKinsey, Platform Strategy 2023

Avant / après : ce qu’une plateforme change vraiment

Avant — patchwork
  • Identité
    Chaque application gère sa propre authentification, ses propres rôles.
  • Intégrations
    Connecteurs point-à-point. N applications = N² intégrations potentielles.
  • Données
    Chaque domaine métier maintient sa copie. Synchronisations fragiles, ETL nocturnes.
  • Observabilité
    Chaque équipe instrumente la sienne. Vision globale impossible.
  • Livraison
    Chaque cas d’usage repart de zéro sur l’infra et la sécurité.
Après — plateforme
  • Identité unifiée
    SSO + IAM centralisés. Les applications consomment l’identité, elles ne la gèrent plus.
  • Bus d’intégration
    Un point d’entrée commun, des contrats d’API standardisés. Complexité linéaire, pas quadratique.
  • Référentiels maîtres
    Une source unique de vérité par domaine (clients, produits, salariés). Le reste consomme.
  • Observabilité centrale
    Logs, métriques, traces unifiés. Décision basée sur des données comparables.
  • Livraison accélérée
    Chaque cas d’usage hérite du socle. Le délai entre besoin et mise en production divise.
Fig. 17.1Avant et après plateformisation : la même équipe livre les mêmes cas d’usage avec une dynamique radicalement différente.

Quatre capacités à mutualiser, le reste à laisser tranquille

Une plateforme efficace ne mutualise que les capacités qui répondent à deux critères : elles sont utilisées par presque tous les cas d’usage, et leur mutualisation produit un effet de levier évident. Quatre capacités passent ce double filtre dans la quasi totalité des SI modernes.

L’identité. SSO, MFA, gestion du cycle de vie des accès, fédération avec partenaires. Aucune raison sérieuse de la dupliquer par application en 2026.

L’intégration. Bus de messages, gestion d’API, gateway, contrats standardisés. Permet aux applications de communiquer sans dépendance directe l’une à l’autre.

Les données maîtres. Référentiels clients, produits, salariés. Un seul lieu de vérité, les autres consomment. Évite les synchronisations divergentes qui coûtent une fortune à maintenir.

L’observabilité. Logs, métriques, traces, tableaux de bord communs. Sans cela, chaque équipe travaille avec ses propres chiffres, et toute discussion devient un débat sur la mesure plutôt que sur le sujet.

Comment ne pas faire de la plateforme une fin

Le piège ultime : la plateforme devient un projet en soi, avec son équipe, sa roadmap, ses livraisons trimestrielles — déconnectées des cas d’usage métier. Pour l’éviter, deux principes opérationnels.

Premier principe : chaque brique plateforme doit avoir un consommateur identifié au moment où on la livre. Pas "potentiellement utile", pas "stratégique" — un cas d’usage métier précis qui l’attend pour avancer.

Deuxième principe : la plateforme est mesurée sur les cas d’usage qu’elle débloque, pas sur sa propre roadmap. Un indicateur clé : le délai entre un nouveau besoin métier et sa mise en production. Si ce délai n’a pas baissé après dix-huit mois de plateforme, le programme est en échec, peu importe ce qui a été livré.

Ce qu’il faut retenir

  • Plateformiser ne veut pas dire centraliser. C’est mutualiser quatre capacités précises : identité, intégration, données maîtres, observabilité.
  • Le piège : vouloir mutualiser des capacités à forte spécificité métier (workflow, UI). Elles deviennent des usines à gaz génériques qui ne servent personne.
  • Le seul KPI qui compte : délai entre un besoin métier et sa mise en production. S’il ne baisse pas, votre plateforme ne sert qu’à elle-même.