Les programmes de transformation agile à l’échelle (souvent incarnés par SAFe) se multiplient dans les grandes DSI. Beaucoup d’ETI engagées dans une transition DevOps explorent ou adoptent SAFe pour structurer leurs sprints à grande échelle. Sauf que la gouvernance IT, elle, n’est pas forcément taillée pour ce nouveau mode de fonctionnement, piloté par la valeur et la synchronisation continue. Du coup, on se retrouve souvent avec un schéma « SAFe sur le papier, vieilles habitudes en pratique ». Faut-il pour autant revoir en profondeur la gouvernance IT ? Ou peut-on juste plaquer SAFe sur l’existant ?
Ce que SAFe apporte : transparence, pilotage par la valeur, synchronisation
SAFe (Scaled Agile Framework) propose un cadre : squads, trains, PIs (Program Increments), tout pour organiser un grand nombre d’équipes autour d’un backlog global, avec des itérations synchronisées.
L’ambition : casser les silos, faire converger la technique et le métier, livrer régulièrement en priorisant la valeur.
- En théorie, c’est super attirant : plus de projets interminables, place à un flow continu d’évolution, géré via la roadmap des features.
- En pratique, SAFe oblige à plus de transparence (tout le monde voit le backlog, la progression), plus de pilotage par la valeur (on ne finance pas un grand budget, on finance des fonctionnalités priorisées), et une synchronisation entre équipes pour éviter le chaos quand on a 20 squads en parallèle.
Ce que SAFe ne dit pas : les décisions stratégiques d’architecture, de sourcing ou de budget
Un malentendu courant consiste à croire que SAFe résout tout, y compris la gouvernance IT pure et dure (qui décide de l’architecture cible, qui valide les choix de sourcing cloud, comment on alloue le budget global, etc.).
Sauf que SAFe ne se positionne pas sur ce volet macro.
Il parle d’un LPM (Lean Portfolio Management), certes, mais c’est davantage une façon d’orienter les budgets sur des « value streams » qu’une redéfinition en profondeur des comités d’architecture ou du cycle de décision pour l’infrastructure.
Du coup, on peut très bien adopter la mécanique SAFe tout en gardant un mode de décision ultra-centralisé sur les aspects techniques. Ce qui peut conduire à des frictions : d’un côté, le train SAFe qui veut avancer itération après itération, de l’autre, un comité architecture mensuel qui valide ou non des orientations cruciales, parfois en contradiction avec la réactivité souhaitée.
La tentation de coller SAFe sur une gouvernance IT existante : un risque réel
Souvent, la direction se dit : « Ok, on lance SAFe sur la partie dev, ça ira plus vite, plus agile, plus tout ». Logique.
Mais tout ça est fait sans toucher au système de gouvernance hérité, ni aux process budgétaires classiques (des budgets en mode annuel, par exemple), ni à la politique d’externalisation IT.
Résultat, la mise en place de SAFe s’ajoute comme un module sur un ERP périmé, et crée une dissonance.
Petit exemple concret : si une équipe SAFe a besoin d’un nouveau microservice pour améliorer la qualité de la release, mais que l’approbation doit passer par 4 comités distincts (architecture, sécurité, finances, sourcing) qui se réunissent chacun tous les 2 mois, on se retrouve loin de la vision « itérative, adaptative » prônée par SAFe. D’où l’impression que SAFe ne marche pas, alors qu’il est juste bridé par une gouvernance inadaptée. Simple, basique.
Le rôle structurant de l’Enterprise Architect dans la nouvelle gouvernance
C’est là que l’on voit émerger le rôle d’« Enterprise Architect ». Dans un cadre SAFe, on parle parfois d’« Architect sync » ou de rôles d’« architects Enablers » qui orientent la technique au fil des increments.
L’idée : avoir des personnes qui veillent à la cohérence globale de l’architecture, sans imposer un cycle de décision archaïque, des pilotes de la roadmap d’architecture, qui bossent avec les squads pour infuser la vision technique.
Grosso modo, l’EA vient s’assurer que tout ce qui est « stratégique » (grands choix d’infrastructure, orientation cloud, standard technologique) soit pris en compte dans les Program Increments, par le biais d’Epics ou d’Enablers techniques. On ne sépare plus les devs en agile et l’architecture dans un bunker : on fait monter la dimension archi dans le backlog SAFe. Mais pour cela, il faut accepter de transformer la gouvernance : l’EA a besoin d’un mandat clair, de rôles bien définis, d’espaces de synchronisation réguliers.
Pour aller plus loin sur ce point, les liens entre SAFe est les démarches d’architecture d’entreprise sont également abordés dans cette interview https://www.projexion.com/carrefour-apprentissage/rex/enterprise-architect-safe/.
Bonnes pratiques pour aligner gouvernance IT, architecture et agilité à l’échelle
En clair, pour bien faire, il vous faudra :
- Repenser le financement : passer d’un budget projet cloisonné à un budget orienté value streams ou programmes. Oublier le mode « on finance un gros projet sur 3 ans » et privilégier l’investissement itératif, revu à chaque PI.
- Réviser les comités : exit la multiplication des comités. On organise un LPM qui inclut un panel d’EA, de RSSI, de business owners, pour fluidifier la validation. On peut maintenir certains comités d’archi, mais il faut réduire la lourdeur ou la fréquence.
- Intégrer l’architecture dans le backlog : l’archi n’est pas hors du backlog. Les enablers techniques doivent être priorisés au même titre que les features métiers, selon la valeur business ou la dette technique à résorber.
- Former les équipes : trop souvent, la DSI ou les squads ne pigent pas les enjeux archi. Donner des sessions de sensibilisation, clarifier le rôle de l’EA, lever l’ambiguïté « SAFe vs. archi monolithe ».
- Suivre et ajuster : pas de big bang. On adopte SAFe, on voit ce qui coince dans la gouvernance, on ajuste en continu. L’important, c’est la cohérence globale, pas l’application stricto sensu d’un livre SAFe.