SAFe, ITIL et le piège ERP multi-éditeur : comment garder le contrôle sans étouffer la livraison

SAFe et ITIL dans un projet ERP : deux rôles distincts, pas deux options

SAFe (Scaled Agile Framework) est un cadre de livraison à l'échelle. Son principe central : des équipes organisées en cycles de 10 à 12 semaines — les PI (Program Increments) — livrent des incréments fonctionnels à condition que les dépendances soient planifiables. C'est-à-dire visibles, stables, et résolubles dans la cadence du cycle.

ITIL est un cadre de gestion des services IT en production. Son organe de validation est le CAB (Comité d'Approbation des Changements — Change Advisory Board), qui contrôle ce qui passe en production indépendamment du rythme de développement.

Ce ne sont pas des alternatives. Ce sont deux périmètres distincts : SAFe gouverne le Build (construire), ITIL gouverne le Run (stabiliser). Les mélanger sans séparation contractuelle claire crée exactement les conditions du blocage.

Le ménage à trois : pourquoi trois parties produisent un seul perdant

Dans un projet d'intégration Teamcenter–SAP CRM avec migration cloud partielle, les trois acteurs avaient des agendas structurellement incompatibles.

L'éditeur pilote sa propre roadmap de versions. Il contrôle l'accès aux spécifications techniques de ses connecteurs — non par mauvaise volonté, mais parce que c'est un avantage concurrentiel inhérent à son modèle économique. Plus les intégrations passent par ses outils natifs, plus la relation client s'inscrit dans la durée. C'est une réalité structurelle documentée par des praticiens SAP : les partenaires de l'écosystème sont incités à recommander les middlewares propriétaires de l'éditeur, ce qui consolide les dépendances techniques — et les contrats. [Confirmé — discussions praticiens, r/SAP, 2023]

L'intégrateur TMA est rémunéré sur un volume d'heures. Son incitatif n'est pas la vélocité — c'est la complexité. Des user stories larges, des spécifications partielles, des dépendances non résolues : tout cela justifie des points de charge élevés et des demandes de changement sur chaque ticket d'attente.

Le client se retrouve entre les deux, sans levier contractuel sur les spécifications de l'éditeur ni sur la cadence de l'intégrateur. Il paie le mouvement, pas le résultat.

Clé n°1 — Contrôler le contrat avant de choisir la méthode

La première erreur est de choisir SAFe ou ITIL avant d'avoir défini les périmètres contractuels. La méthode ne peut pas compenser une gouvernance absente — elle l'aggrave en lui donnant une apparence de rigueur.

Trois périmètres doivent être séparés contractuellement avant la signature, jamais après le premier blocage :

• Support éditeur : incidents, correctifs de sécurité, upgrades de version. Chaque engagement doit inclure des délais de réponse opposables et des conditions d'accès aux spécifications techniques — notamment pour les connecteurs tiers. Ce périmètre relève d'ITIL, pas de SAFe. Il ne doit jamais entrer dans un backlog de sprint.
• TMA évolutive : développements custom, nouvelles intégrations. C'est le périmètre où SAFe s'applique — à condition que les user stories soient spécifiables indépendamment des roadmaps éditeur. La définition du "done" doit être contractuellement opposable : une story ne peut pas être déclarée livrée si sa validation dépend d'une interface non stabilisée.
• Projet d'intégration : jalons de livraison et, point critique, les dépendances éditeur documentées et contractualisées — délais de réponse aux demandes de specs, conditions d'upgrade, accès aux connecteurs. Sans ce cadre, un upgrade éditeur déclenché en cours de projet devient un déclencheur de blocage global.

Clé n°2 — Comprendre pourquoi l'Agile échoue sans maîtrise du code

SAFe — comme toute méthode Agile — repose sur une condition préalable rarement explicitée : les équipes doivent pouvoir spécifier ce qu'elles vont construire. C'est-à-dire avoir accès aux interfaces, aux schémas de données, aux règles de gestion — suffisamment pour décomposer un besoin en user stories avec des critères d'acceptation vérifiables.

Dans un projet ERP multi-éditeur, cette condition n'est pas garantie. Un connecteur — c'est-à-dire le composant logiciel qui permet à deux systèmes distincts d'échanger des données (ici, faire parler Teamcenter et SAP entre eux) — est techniquement une interface : un contrat d'échange de données avec ses propres règles, formats et contraintes. En pratique, cela prend plusieurs formes : une API REST (la plus courante aujourd'hui — le système A envoie une requête, le système B répond avec les données demandées), un service SOAP (un standard plus ancien, encore très présent dans les environnements SAP et Teamcenter hérités), ou des formats d'échange propriétaires comme les IDocs SAP (documents intermédiaires structurés que SAP utilise pour ses échanges entre modules et systèmes tiers). Chacun a ses propres règles de structure, d'authentification et de versioning. Quand les spécifications de ces interfaces sont contrôlées par l'éditeur et seulement partiellement communiquées à l'intégrateur, on ne peut pas estimer correctement ce que l'on ne peut pas spécifier. Une user story devient alors une enveloppe de charge — un conteneur à heures, pas un engagement de livraison.

Les conséquences sur la mécanique Agile sont directes :

• Le backlog n'est pas maîtrisé par l'équipe projet — il est en partie dicté par la disponibilité des informations techniques de l'éditeur.
• La définition du "done" devient inopérante : une story ne peut pas être déclarée terminée si la validation dépend d'une interface dont les specs peuvent changer à la prochaine version.
• La vélocité mesure l'activité, pas la valeur livrée. Les sprints s'enchaînent, le burn-down chart semble sain, rien ne passe en production.

La solution n'est pas d'abandonner SAFe — c'est de le réserver au périmètre où ces prérequis sont réunis, et de contractualiser les conditions d'accès aux specs avant le premier sprint.

Clé n°3 — Configurer le CAB pour qu'il protège, pas pour qu'il bloque

Dans ce projet, le CAB traitait identiquement deux natures de changement fondamentalement différentes :

• Un correctif de sécurité : risque faible, obligatoire, doit être validé en fast-track sous 48 heures.
• Un déploiement de module custom : risque élevé, doit passer par une revue avec tests d'intégration complets.

Traités dans la même file, les correctifs critiques attendaient plusieurs semaines. Pendant ce temps, l'intégrateur facturait chaque ticket d'attente en demande de changement.

Ce dysfonctionnement a une cause architecturale sous-jacente : les customisations étaient intégrées directement dans le cœur applicatif plutôt que posées sur une couche d'extension stable. Résultat : tout changement touchait les mêmes composants, rendant toute différenciation par le CAB impossible en pratique.

C'est ici que les deux niveaux de décision — architecture et gouvernance — se rejoignent : une customisation patchée dans le cœur applicatif crée une dépendance que ni SAFe ni ITIL ne peuvent absorber. SAFe ne peut pas planifier un backlog dont les specs changent à chaque roadmap éditeur. ITIL ne peut pas différencier un correctif de sécurité d'un déploiement custom si les deux touchent les mêmes composants. L'architecture conditionne si la séparation Build/Run est gouvernable. Ce point doit être évalué avant la signature — pas découvert au premier upgrade.

Un CAB correctement configuré comporte au minimum deux voies : une voie fast-track pour les changements à faible risque et impact limité, et une voie de revue complète pour les changements à fort impact ou portée étendue. Cette différenciation doit être documentée dans le contrat de support éditeur, pas laissée à l'appréciation du comité réuni en urgence.

Et si vous êtes déjà sous contrat ?

Tout ce qui précède s'applique idéalement en amont de la signature. Mais la réalité de terrain est différente : beaucoup de DSI lisent cet article alors qu'ils sont déjà engagés — un contrat TMA en cours, un support éditeur actif, un projet d'intégration qui a démarré sans cette séparation.

Dans ce cas, trois opportunités à ne pas laisser passer :

• Le renouvellement de contrat est la fenêtre de renégociation principale. Un contrat TMA ou de support éditeur qui arrive à échéance est l'occasion de reposer les périmètres, d'introduire des SLA différenciés et d'exiger l'accès documenté aux spécifications des interfaces. Ne laissez pas un renouvellement tacite reconduire les mêmes failles.
• La synchronisation des échéances est souvent sous-estimée. Si votre contrat TMA se renouvelle en juin et que la roadmap Teamcenter prévoit un upgrade en septembre, la fenêtre de renégociation est avant juin — pas après l'upgrade. Cartographier les dates clés de chaque contrat et de chaque roadmap éditeur permet d'anticiper les points de friction plutôt que de les subir à chaque cycle.
• Un incident majeur est aussi une opportunité. Un blocage documenté — un upgrade qui a paralysé le projet, un correctif critique bloqué plusieurs semaines en file CAB — constitue un argument contractuel concret pour renégocier les conditions. Documentez systématiquement les impacts, les délais et les coûts associés.

Le message est simple : si vous ne pouvez pas agir avant la signature, agissez à la prochaine fenêtre contractuelle. Et si cette fenêtre n'est pas visible, commencez par la cartographier.

Ce que cela change concrètement pour votre programme ERP

Votre programme ERP multi-éditeur est-il gouverné — ou subi ?

Si vos sprints livrent de l'activité sans résultat en production, si votre CAB bloque les correctifs critiques au même titre que les évolutions custom, ou si vos intégrateurs facturent l'attente plutôt que le progrès — le problème n'est ni SAFe, ni ITIL. C'est l'absence de séparation contractuelle entre Build et Run, établie avant le démarrage du programme.

Les points de friction sont prévisibles. Un diagnostic de gouvernance gratuit permet de les identifier et de les contractualiser en amont — avant qu'ils ne deviennent des blocages facturés. Si vous souhaitez d'abord comprendre comment structurer votre approche, notre page conseil en transformation numérique détaille le cadre d'intervention.