PME/ETI : conduire le changement avec PRINCE2, Scrum et un Product Owner sénior

Conduire le changement dans une PME ou une ETI : comment articuler PRINCE2, Scrum et un Product Owner sénior après vos auto-diagnostics

Changer ne consiste pas seulement à décider une nouvelle direction. Pour une PME ou une ETI, la vraie difficulté est de relier un diagnostic clair, une gouvernance crédible et une capacité d’exécution concrète. C’est précisément ce que permet un dispositif combinant PRINCE2, Scrum et un Product Owner sénior.

---

Pourquoi les auto-diagnostics ne suffisent pas à eux seuls

Un diagnostic produit de la lucidité, pas encore du mouvement

Un bon diagnostic stratégique fait mal dans le bon sens. Il met des mots sur ce que tout le monde pressentait sans pouvoir le formuler : le problème central, les angles morts, les ressources gaspillées sur le mauvais levier. C’est sa valeur. Ce n’est pas sa limite.

La limite, c’est qu’un diagnostic ne décide rien. Il ne priorise pas. Il ne structure pas la séquence des actions. Il ne dit pas qui décide quoi, à quel rythme, avec quelle marge de manœuvre. Il crée les conditions d’une décision lucide, à charge de l’entreprise d’en faire quelque chose.

Le risque classique : voir juste, mais ne pas transformer, ne rien changer

Le scénario le plus fréquent après un diagnostic ? Un CODIR qui partage les résultats, quelques réunions de travail, un plan d’action qui rejoint les autres plans d’action, et un retour progressif à l’opérationnel dominant. Pas par mauvaise volonté. Par manque de dispositif.

Sans gouvernance explicite, sans rôles clairs et sans cadence d’exécution, la lucidité produite par le diagnostic se dissout dans le run. L’organisation revient à son équilibre antérieur, exactement ce que Berne appelle l’homéostasie organisationnelle, et que tout praticien de la transformation reconnaît sans avoir besoin du mot.

Ce que les quatre diagnostics révèlent réellement sur l’entreprise

Les quatre outils du cadre ÉMERGENCE : Diagnostic Stratégique, Diagnostic TOM, Diagnostic Organisation Design et Test d’Archétypes Décisionnels, ne sont pas quatre tableaux de bord indépendants. Lus ensemble, ils révèlent des tensions de pilotage : là où l’organisation se grippe, où les décisions ne se prennent pas ou se prennent mal, où les ressources partent dans la mauvaise direction.

C’est précisément ce matériau que PRINCE2, Scrum et un Product Owner sénior permettent de transformer en dispositif opérationnel pour réaliser les transformations nécessaires.

---

Ce que disent vraiment les quatre diagnostics

Diagnostic stratégique : du problème central à la politique directrice

Le Diagnostic Stratégique (Kernel de Rumelt) identifie trois choses : le problème central, celui qui, si on ne le résout pas, rend tous les autres efforts peu utiles.La politique directrice, c’est-à-dire les grands choix qui orientent l’action, et les actions cohérentes qui se renforcent mutuellement.

Ce diagnostic dit rarement que l’entreprise doit « s’améliorer en général ». Il dit : voici où vous perdez de l’énergie structurellement, voici le levier qui change le reste. C’est la matière première du backlog de transformation.

Diagnostic TOM : arbitrer entre run et build

Le Diagnostic TOM mesure la tension run/build : quelle part des ressources allez-vous allouer à maintenir l’existant et quelle part va construire votre avenir. La plupart des PME/ETI découvrent ici que 80 à 90 % de leur énergie est absorbée par le ru et que le build, même quand il existe, est mal délimité et sous-piloté.

Run vs Build : la confusion qui ralentit beaucoup de PME/ETI

Le run, c’est ce qui fait tourner l’entreprise aujourd’hui : production, commercial, support, administration. Le build, c’est ce qui construit sa capacité de demain : nouveaux processus, nouvelles offres, nouvelles compétences, nouvelles organisations. La confusion vient du fait qu’on met souvent du build dans du run (un projet de transformation géré comme une urgence opérationnelle) ou du run dans du build (une amélioration continue confondue avec une transformation). PRINCE2 et Scrum s’appliquent au build. Leur première utilité est de le rendre visible et de le protéger.

Diagnostic organisationnel : clarifier rôles, interfaces et responsabilités

Le Diagnostic Organisation Design (modèle Star) ausculte la cohérence entre structure réelle, mécanismes de coordination, systèmes de pilotage et capacités. Il fait apparaître les flous de responsabilité, les décisions qui remontent systématiquement, les interfaces entre fonctions qui ne fonctionnent pas, et les modes de coordination inadaptés à la stratégie.

Ces résultats alimentent directement la clarification des rôles dans le dispositif cible.

Archétypes décisionnels : comprendre comment l’entreprise décide réellement

Le Test d’Archétypes Décisionnels (Test Nature Humaine) révèle les profils cognitifs et décisionnels dominants dans l’équipe dirigeante. Il dit comment les décisions se prennent réellement par intuition, par consensus, par analyse, par autorité  et où les biais collectifs créent des angles morts.

C’est la matière première des règles de gouvernance à installer : si l’équipe décide lentement par excès de consensus, la gouvernance doit structurer des seuils de délégation explicites. Si elle décide trop vite par dominant intuitif, elle doit installer des points de revue formels.

---

Diagnostic	Ce qu’il mesure	Ce qu’il révèle	Risque si on n’agit pas	Conséquence sur le dispositif cible
Stratégique	Clarté du problème central et des leviers	Focalisation (ou non) des ressources sur l’essentiel	Énergie dispersée, priorités instables	Définit le périmètre et les priorités du backlog
TOM	Ratio run/build et maturité d’exécution	Capacité réelle à conduire un build	Build absorbé par le run	Dimensionne la charge build disponible et protège le ratio
OD	Cohérence structure / stratégie / coordination	Frictions internes, flous de responsabilité	Résistances silencieuses, décisions lentes	Clarifie rôles, interfaces et mécanismes de coordination
Archétypes	Modes de décision réels de l’équipe	Biais collectifs, vitesse et qualité des arbitrages	Gouvernance inadaptée au profil dirigeant	Calibre les instances et les seuils de délégation

Lecture croisée des diagnostics

---

Pourquoi un dispositif hybride est souvent plus adapté qu’une méthode unique

Les limites d’une conduite du changement uniquement descendante

Une transformation pilotée uniquement du sommet, plan d’action CODIR, jalons trimestriels, reporting ascendant, présente un avantage : la cohérence stratégique est protégée. Elle présente un défaut majeur : la capacité d’adaptation en cours de route est quasi nulle. Dès que le terrain diverge du plan (ce qui arrive toujours), les équipes n’ont pas les moyens d’arbitrer localement. Elles attendent. Ou pire, elles font semblant d’avancer.

Les limites d’une agilité sans gouvernance forte

À l’inverse, une approche purement agile dans une PME/ETI sans culture projet structurée produit souvent du mouvement sans direction, voir de l’agitation. Les sprints s’enchaînent, les backlogs grossissent, les équipes s’activent, mais le lien avec la stratégie se perd, les arbitrages de priorisation se font au feeling, et le CODIR ne sait plus quoi financer ni quand.

Pourquoi l’hybridation PRINCE2 et Aigle Scrum est pertinente en PME/ETI

Ce que PRINCE2 change pour un dirigeant de PME

PRINCE2 n’est pas une bureaucratie projet. C’est un cadre de gouvernance : il pose les questions que tout projet devrait se poser avant de démarrer et à chaque étape. Pourquoi ce projet est-il justifié ? Qui décide ? Jusqu’où délègue-t-on ? Quand s’arrête-t-on si ça ne fonctionne pas ? Pour un dirigeant de PME, son utilité principale est de protéger la cohérence stratégique tout en donnant de la visibilité sur l’avancement. Allégé, il se réduit à quelques rôles clairs, un dossier de justification, et des points de contrôle à intervalles définis.

PRINCE2 structure la colonne vertébrale : la justification continue du projet, les rôles, les étapes, les seuils de décision. Scrum cadence l’exécution : des cycles courts, une priorisation permanente, des apprentissages intégrés en temps réel. Les deux ne se contredisent pas, ils opèrent à des niveaux différents. PRINCE2 tient le cadre, Scrum fait avancer le travail à l’intérieur.

---

PRINCE2 : la colonne vertébrale de votre changement

Ce que PRINCE2 apporte à une organisation de 10 à 250 personnes

PRINCE2 (Projects IN Controlled Environments) est un cadre de management de projet fondé sur sept principes, dont les plus utiles en PME/ETI sont :

• Justification continue : le projet doit rester justifié à chaque étape. Si la raison d’être disparaît, on arrête.
• Rôles et responsabilités définis : qui est sponsor, qui dirige le projet, qui produit le travail.
• Management par étapes : on n’autorise qu’une étape à la fois, ce qui force les points de revue et les arbitrages.
• Management par exception : le CODIR ne s’occupe pas de tout, il intervient uniquement quand les seuils de tolérance sont franchis.

Les principes les plus utiles en contexte PME/ETI

En pratique, deux principes changent vraiment les choses dans une structure légère.

Le management par exception libère le CODIR du suivi opérationnel sans le déresponsabiliser. Le chef de projet ou le Product Owner gère dans ses marges de manœuvre ; il remonte uniquement quand il en sort. Cela suppose d’avoir défini ces marges, ce que la plupart des PME ne font jamais explicitement.

La justification continue force une question que les organisations évitent : est-ce qu’on continue ce projet pour de bonnes raisons, ou parce qu’on a commencé ? C’est le meilleur antidote au sunk cost et aux projets zombies qui absorbent du run sans livrer de build.

Comment alléger PRINCE2 sans le vider de sa valeur

PRINCE2 s’allège en supprimant les livrables documentaires non utiles à la taille de l’organisation. Ce qui ne s’allège pas : les rôles (sponsor, chef de projet, équipe), le business case (même d’une page), les étapes et leurs seuils de tolérance, et la distinction nette entre gouvernance et exécution. Retirer ces éléments n’allège pas PRINCE2, ça le supprime.

 

 

---

Scrum : mettre le changement en mouvement

Pourquoi Scrum aide à exécuter sans attendre la perfection

Scrum repose sur un principe simple : on n’attend pas d’avoir tout planifié pour commencer. On définit une priorité, on travaille dessus sur une durée courte (le sprint, généralement deux semaines), on livre quelque chose de tangible, on apprend, on ajuste les priorités. Ce cycle court est particulièrement adapté aux transformations où les conditions changent et où les apprentissages de terrain modifient les choix.

Ce que Scrum change pour une équipe de transformation

Scrum ne supprime pas la complexité, il la rend gérable par petits morceaux. Pour une équipe habituée au run, l’effet principal est la visibilité : on sait ce sur quoi on travaille cette quinzaine, pourquoi c’est prioritaire, et si on a avancé. Les revues de sprint rendent les progrès concrets et donnent aux managers des occasions régulières de réorienter sans attendre la prochaine réunion trimestrielle. Les rétrospectives créent une discipline d’apprentissage collectif qui fait souvent défaut dans les PME/ETI.

Backlog, sprints, revues, rétrospectives : à quoi ça sert vraiment

• Le backlog : liste priorisée de tout ce qui doit être fait. Sa valeur n’est pas d’être exhaustif mais d’être trié, le plus important en haut, le reste en dessous.
• Le sprint : période fixe (deux semaines en général) pendant laquelle l’équipe s’engage sur un périmètre. Ce qui entre dans un sprint ne change pas pendant le sprint.
• La revue : démonstration de ce qui a été produit. Elle force à livrer du concret, pas du « en cours ».
• La rétrospective : que faire différemment au prochain sprint ? Elle installe une discipline d’amélioration continue qui manque souvent dans les transformations.

Comment adapter Scrum à des équipes non techniques ou mixtes

Scrum est né dans le développement logiciel. Il s’applique parfaitement à des chantiers de transformation non techniques : refonte de processus, évolution de l’offre, réorganisation d’une fonction, déploiement d’une gouvernance. L’adaptation principale : remplacer « incrément logiciel » par « livrable de transformation », un processus documenté et testé, un rôle clarifié et opérationnel, une instance installée et rodée. Le critère reste le même : est-ce que c’est fait, ou est-ce que c’est en cours ?

---

Le Product Owner sénior : pivot entre stratégie, métiers et delivery

Pourquoi ce rôle devient critique après un auto-diagnostic

Un diagnostic ÉMERGENCE produit du matériau stratégique : tensions, leviers, priorités. Ce matériau doit être traduit en décisions opérationnelles, en séquence de travail, en arbitrages permanents entre l’urgent et l’important. C’est exactement ce que fait un Product Owner sénior.

Sans ce rôle, le diagnostic reste dans les slides du CODIR. Les équipes reçoivent des orientations générales mais pas de backlog priorisé. Chacun interprète les priorités à sa façon. Le run reprend le dessus.

Le vrai rôle d’un Product Owner sénior

Un PO sénior n’est pas un chef de projet qui fait du Scrum. C’est un traducteur de valeur : il comprend la stratégie (problème central, politique directrice, cibles TOM et OD), il parle aux métiers, et il tient le backlog de transformation en ordre de bataille. Il arbitre en permanence : est-ce qu’on fait ça maintenant parce que c’est prioritaire, ou parce que c’est pratique ? Son autorité sur le backlog est non-négociable. Sans elle, le rôle est cosmétique.

Ce qu’un PO sénior fait concrètement dans une PME/ETI

• Il tient et priorise le backlog de transformation, en lien direct avec les résultats des diagnostics
• Il traduit la politique directrice en user stories ou épics de transformation compréhensibles par les équipes
• Il arbitre les demandes concurrentes entre métiers, sans les renvoyer systématiquement au CODIR
• Il participe aux revues de sprint et valide que ce qui est livré correspond à ce qui était attendu
• Il remonte au sponsor les déviations qui dépassent ses seuils de tolérance, pas avant

Ce que ce rôle n’est pas

Pas un assistant du CODIR chargé de faire les comptes rendus. Pas un chef de projet bis qui gère le planning et les ressources. Pas un gestionnaire de backlog qui prend les demandes sans les prioriser. Sa valeur est dans la décision de priorisation, pas dans l’exécution.

---

Comment relier les diagnostics au dispositif cible

C’est la section la plus importante. Elle fait le pont explicite entre ce que les diagnostics révèlent et ce que le dispositif doit faire.

Du problème central au portefeuille de priorités

Le problème central Rumelt devient le filtre de toutes les décisions de backlog. Toute initiative qui ne contribue pas à le résoudre est déprioritisée, pas abandonnée, mais mise en dessous. C’est le premier arbitrage que le PO sénior doit être capable de tenir face à la pression des métiers.

De la politique directrice au backlog de transformation

La politique directrice (les grands choix structurants) se traduit en épics : des chantiers de transformation de plusieurs sprints, qui ont une orientation claire, un résultat attendu et un critère de validation. Chaque epic contient des items plus petits sur lesquels les équipes travaillent sprint par sprint.

Du TOM cible à la distinction run / build

Le TOM cible dit comment l’entreprise doit fonctionner demain. La distance entre aujourd’hui et cette cible est le périmètre du build. Ce périmètre doit être rendu visible, budgété et protégé, sinon il est constamment cannibalisé par le run. PRINCE2 protège ce périmètre via la justification continue et les étapes contrôlées. Scrum l’exécute via des sprints dédiés.

De l’OD cible à la clarification des rôles

Les résultats du Diagnostic Organisation Design font apparaître des flous de responsabilité et des interfaces dysfonctionnelles. Ces flous sont des items du backlog : clarifier le rôle X, redéfinir l’interface entre les fonctions A et B, installer le comité C avec les bons mandats. Ce ne sont pas des sujets RH ou organisationnels abstraits, ce sont des livrables de transformation.

Des archétypes décisionnels aux règles de gouvernance

Le Test d’Archétypes Décisionnels dit comment l’équipe décide réellement. Cette connaissance calibre les instances : fréquence des comités de pilotage, niveau de délégation accordé au PO et au chef de projet, seuils de tolérance avant remontée. Une équipe à fort profil analytique aura besoin de rituels de revue outillés. Une équipe à fort profil intuitif aura besoin de garde-fous formels pour éviter les décisions prématurées.

---

Le modèle cible de gouvernance pour une PME/ETI

Qui décide : sponsor, comité de pilotage, chef de projet, PO, équipe

Rôle	Mission	Décisions autorisées	Fréquence d’intervention	Point de vigilance
Sponsor (dirigeant / membre CODIR)	Protège la justification du projet, arbitre hors tolérance	Arrêt ou réorientation du projet, allocation de ressources	Mensuelle + exceptions	Doit rester disponible sans micro-gérer
Comité de pilotage	Valide les étapes, autorise la suivante	Passage d’étape, ajustement de périmètre	Par étape PRINCE2 (4 à 8 semaines)	Ne doit pas devenir un reporting de suivi
Chef de projet	Gère le cadre PRINCE2, coordonne avec le PO	Décisions dans les tolérances définies	Permanent	Doit avoir une autorité réelle sur le planning et les ressources
Product Owner sénior	Tient et priorise le backlog, valide les livrables	Priorisation des items, acceptation ou rejet des livrables	Permanent (sprints)	Son autorité sur le backlog est non-négociable
Équipe de transformation	Exécute les sprints, fait remonter les obstacles	Décisions techniques et de méthode à l’intérieur des sprints	Sprints (2 semaines)	Doit être protégée des interruptions run pendant le sprint

Répartition des rôles dans le modèle hybride

Quelles instances installer sans alourdir l’organisation

Pour une PME/ETI, trois instances suffisent :

• Un comité de pilotage mensuel (30 à 45 minutes) : validation des étapes, arbitrage des écarts hors tolérance
• Une revue de sprint bimensuelle (1 heure) : démonstration des livrables, ajustement des priorités
• Une rétrospective à chaque fin de sprint (45 minutes) : amélioration continue du dispositif lui-même

Ce n’est pas lourd. C’est 4 à 5 heures par mois pour piloter une transformation. La vraie charge est dans la préparation de ces instances et c’est le travail du PO et du chef de projet, pas du CODIR.

---

À quoi ressemble une mise en œuvre réussie sur 6 à 12 mois

Phase 1 : Restitution et alignement (semaines 1 à 3)

Le CODIR se réunit pour lire les diagnostics ensemble, pas pour les recevoir en présentation, mais pour en débattre. Quel est le problème central sur lequel tout le monde s’aligne ? Quelle est la politique directrice ? Quels chantiers en découlent ? Cette phase produit un premier backlog de transformation brut et désigne le sponsor et le Product Owner sénior.

Phase 2 : Cadrage du pilote (semaines 4 à 6)

On choisit un périmètre pilote : un chantier prioritaire, une équipe volontaire, un résultat tangible attendu à 8 semaines. Le PO affine le backlog du pilote. Le chef de projet rédige une justification courte (business case allégé). Le comité de pilotage autorise le démarrage. On installe les rituels Scrum.

Phase 3 : Exécution incrémentale (semaines 7 à 20)

Quatre à six sprints sur le périmètre pilote. Chaque sprint produit un livrable concret et visible. Le CODIR reçoit un point mensuel court. Les ajustements de priorité se font en revue de sprint, pas dans des réunions ad hoc.

Phase 4 : Apprentissage et extension (à partir du mois 6)

Bilan du pilote : qu’est-ce qui a fonctionné ? Qu’est-ce qu’on fait différemment ? Le modèle de gouvernance est affiné, les rôles sont clarifiés, et on ouvre un ou deux chantiers supplémentaires avec la même mécanique.

---

Les conditions de réussite à réunir dès le départ

Condition de réussite	Ce qu’on observe quand elle est présente	Signal d’alerte	Action correctrice
Sponsor réellement engagé	Il participe aux comités de pilotage, arbitre vite, protège le build	Absences répétées, décisions retardées	Reposer explicitement la question de la priorité stratégique
Mandat clair pour le PO	Il priorise sans remonter chaque décision au CODIR	Chaque arbitrage remonte, le backlog est instable	Définir et formaliser son périmètre de décision
Managers intermédiaires embarqués	Ils libèrent du temps pour les sprints, ne sabotent pas le build	Equipe tiraillée entre run et sprints	Rendre le ratio run/build visible et négocier la protection du build
Indicateurs simples et partagés	On sait en 5 minutes si le sprint a avancé	Reporting complexe, métriques floues	Réduire à 3 indicateurs max par sprint
Discipline de revue et d’apprentissage	Les rétrospectives existent et produisent des changements	Rituels sautés dès la première pression	Traiter les rituels comme non-négociables pendant les 3 premiers mois

Conditions de réussite et signaux faibles d’échec

---

Les erreurs les plus fréquentes

5 signes qu’un dispositif de transformation est mal calibré

1. Le Product Owner est nommé mais son backlog est réécrit à chaque CODIR.
2. Les sprints existent mais l’équipe est constamment interrompue par le run.
3. Le comité de pilotage se réunit pour valider des slides, pas des livrables.
4. Le business case du projet n’a jamais été mis à jour depuis le lancement.
5. Tout le monde est « impliqué » dans la transformation, mais personne n’en est vraiment responsable.

Nommer un PO sans autorité réelle. C’est la pathologie la plus courante. Un PO dont le backlog est redéfini par le CODIR à chaque réunion n’est pas un PO, c’est un secrétaire de séance. L’autorité sur la priorisation est la condition d’existence du rôle.

Faire de Scrum un rituel sans priorisation ferme. Les sprints s’enchaînent, les réunions ont lieu, mais le backlog est une liste de souhaits sans ordre de priorité défendu. Le résultat : de l’agitation, pas de la progression.

Conserver un run qui absorbe toute l’énergie disponible. Si les équipes sont à 100 % sur le run, aucun dispositif build ne fonctionnera. La première décision concrète d’une transformation est de protéger du temps pour le build, même 15 à 20 % au départ.

Multiplier les comités et ralentir les arbitrages. Chaque comité supplémentaire est une décision retardée. Le modèle de gouvernance doit être conçu pour accélérer les arbitrages, pas pour les distribuer.

Vouloir transformer toute l’entreprise d’un seul coup. Une transformation globale et simultanée dans une PME/ETI épuise les équipes et dilue l’attention du CODIR. Un pilote ciblé sur un périmètre à forte valeur apprend plus vite et convainc mieux que dix chantiers en parallèle.

---

Par où commencer concrètement

Identifier un périmètre pilote à forte valeur

Le périmètre pilote doit répondre à trois critères : il est directement lié au problème central identifié dans le Diagnostic Stratégique, il est délimitable (une équipe, un processus, une offre), et son résultat sera visible en moins de trois mois. Ce n’est pas le chantier le plus facile, c’est le chantier le plus révélateur.

Choisir les rôles et poser les mandats

Avant le premier sprint, trois questions doivent avoir une réponse écrite : qui est le sponsor et jusqu’où peut-il déléguer ? Qui est le Product Owner et quel est son périmètre de décision sur le backlog ? Qui compose l’équipe et quelle part de son temps est protégée pour le build ?

Installer un premier backlog de transformation

Pas une liste de tâches. Un backlog priorisé avec, pour chaque item : ce qu’on veut produire, pourquoi c’est prioritaire maintenant, et comment on saura que c’est fait. Dix items bien écrits valent mieux qu’une centaine de post-its.

Programmer les premières revues de pilotage

Le premier comité de pilotage, la première revue de sprint, la première rétrospective. Ces trois dates, posées avant le démarrage, signalent que le dispositif est réel, pas un mode projet déclaratoire. Ce sont aussi les trois moments où on apprend le plus vite si le dispositif est bien calibré.

---

Vous avez complété un ou plusieurs diagnostics ÉMERGENCE et vous vous interrogez sur la suite ? Les diagnostics Stratégique, TOM et Organisation Design sont disponibles gratuitement sur coesor.fr, résultats immédiats, anonymes, sans inscription. La question de ce qu’on en fait ensuite, c’est une autre conversation.