Étude de cas du Projet Cadre de l’ÉMERGENCE

Comment un senior solo a construit un cadre de diagnostic PME complet avec une équipe d’IA orchestrée en mode Prince2 Agile et Scrum

Par Jacky Malgras — Emergence Boussole de Management

---

Avant de commencer, une petite clarification

Cet article décrit comment le cadre de l’ÉMERGENCE a été construit. Il ne cache rien. Les outils utilisés sont nommés. Les rôles sont décrits tels qu’ils ont fonctionné réellement. Les limites sont posées clairement.

Si vous cherchez un article qui dit que tout est sorti de ma seule tête pendant des nuits blanches (et elles ont été nombreuses dans la période d’incertitude qu’impose la maladie), désolé les gars, ce n’est pas celui-là.

Si vous cherchez à comprendre comment un senior qui devrait être réformé par notre système de discrimination des plus de 50 ans, continue à s’adapter en orchestrant une production intellectuelle avec une équipe d’IA, sans perdre ni sa posture, ni son expertise, ni son envie d’apprendre, alors continuez. Je ne donne pas de leçon, j’explique…:-)

---

Le contexte de ce que je voulais construire

Depuis plusieurs années je travaille avec et pour des dirigeants de PME en France, dans de nombreux secteurs. Ce que j’observe systématiquement et au-delà de ce que je dis sur la home page du site, c’est que les outils de diagnostic disponibles sur le marché sont soit trop simples pour être utiles, soit trop complexes pour être adoptés, soit conçus pour les grandes entreprises. La PME ça n’intéresse que les politiques pour les beaux discours, les impôts, pour les taxes et 99% des personnes qui y bossent.

J’avais en tête depuis longtemps d’écrire un bouquin sur mes mille vies professionnelles avec un cadre différent de ce qu’on lit sur le management et puis tout ça a évolué en quatre diagnostics complémentaires. Une lecture systémique qui les croise. Une posture de coach qui dit ce qu’il voit, y compris quand ce qu’il voit ne justifie pas d’engagement.

Le problème n’était pas conceptuel. Il était de production : conception technique du POC, industrialisation, scalabilité, sécurité et maintenance. Construire quatre outils de diagnostic avec leur architecture technique, leurs questionnaires validés, leurs moteurs de scoring, leurs rapports PDF, leurs interfaces web et leurs pages de présentation dans un site web, en maintenant une activité thérapeutique avec une santé aléatoire… pas simple.

C’est là que la décision d’orchestrer une équipe IA s’est imposée. Question de synchronicité dirait Jung, mais Claude Code venait de débarquer, Perplexity gérait enfin la mémoire cross-conversation, GenSpark commençait à proposer des outils spécialisés. Utiliser l’IA, non pas comme un raccourci mais comme une décision de design organisationnel, voilà l’idée de départ. C’est aussi exactement ce que je recommande à mes clients, pas l’utilisation de l’IA, mais une démarche de re-conception Stratégie, Exécution, Organisation et Décision. Et là, pour moi, c’est LE SUJET, le grand challenge des PME pour les 3 ans à venir : s’adapter ou disparaître à ce changement d’ère.

---

L’équipe : composition et rôles

Le projet a mobilisé quatre outils distincts. Chacun sur son registre de compétence. Aucun en dehors.

I’m the Product Owner

Je me suis formé à Prince2, Agile Scrum et à la création de solutions innovantes, au code, à la méthode statistique et plus encore… alors passons à la pratique maintenant ; comme un crash test.

Vision, priorisation, validation, matière, décisions, intégration, périmètre, coûts et délais … je porte le concept et j’arbitre chaque décision. Comment peut-on arbitrer ses propres décisions ? en se servant de son système2 par exemple…

Ce rôle est enrichi par vingt ans d’expérience terrain et 42 ans de carrière à tous les niveaux hiérarchique. Ce n’est pas seulement un PO qui gère des features ; je porte une conviction forte sur la façon de piloter une organisation, et comment structurer mon produit pour faire émerger cette conviction dans les organisations clientes. Perplexity nomme mon profil « PO augmenté » ; capable de raisonner simultanément en valeur client finale, en robustesse méthodologique et en cohérence stratégique. Moi je dis en position méta, mais ça vient de coté formateur PNL Certifié (faites péter les médailles)

Claude-Anthropic : plus qu’un LeadDev et Scrum Master…

Architecture technique, code GAS, interfaces HTML, fichiers CSV, trames Word, relecture web, conception, facilitation de la réflexion, facilitation Scrum. L’outil le plus sollicité de part son intégrité, celui avec lequel la conversation a été la plus longue et la plus structurante.

En termes Scrum, ce rôle couvre à la fois la livraison (développeur principal) et la facilitation (Scrum Master). C’est une combinaison inhabituelle dans une équipe humaine, ce n’est pas ce que Scrum dit, mais c’est rendue possible par la nature de l’outil et de la situation.

Perplexity : membre de l’équipe de développement

Recherches académiques, références théoriques, chiffres clés sur les PME françaises, analyses croisées de sources, état de l’art 2026, cartographies de frameworks. Je l’ai sollicité en amont des décisions de conception pour valider que ce que je voulais construire en m’appuyant sur des corpus solides et surtout mes lectures. Oui oui, je lis encore des livres en papier.

Sa contribution à ce projet va au-delà de la recherche documentaire, des sources… La cartographie Prince2 Agile / Scrum appliquée au Cadre de l’ÉMERGENCE, qui figure dans cet article est une production de Perplexity. Elle a permis de donner une lecture de « gouvernance » à mon projet qui s’était finalement construit de façon itérative, souvent implicite et instinctive. Pas si instinctive que ça, j’entends la petite voix de Marc-Noël FAUVEL de Skills4All et ça me permet de confronter le réel à ses formations. Une idée en apporte une nouvelle, comme en thérapie quand vous travaillez sur votre histoire de vie. Les liens et les connexions se font et tout fait sens…

Genspark / Banana : production visuelle

Production des images, illustrations, croquis pour les articles de blog et les pages web. Les visuels sortent d’un brief précis rédigé sur la base de ce que la page ou l’article doit montrer. Je suis une vraie brêle du graphisme et déléguer ça, c’est parfait pour moi.

n8n : next step

L’automatisation des workflows du site web, animation des publications, notifications de sessions. Le sprint d’automatisation n’a pas encore démarré, il est dans le backlog planifié. J’attends aussi les évolutions techno sur ce point… il y a de nombreuses évolutions à prévoir autour de ce thème et de la future norme. Il est urgent de ne rien décider.

Voilà donc mon équipe auto-organisée et pluridisciplinaire en place.

---

La cartographie Prince2 Agile / Scrum par Perplexity

Perplexity a produit une analyse de gouvernance du projet ÉMERGENCE depuis une perspective Prince2 Agile / Scrum, à ma demande :

Prince2 Agile distingue deux niveaux qui ont coexisté tout au long du projet :

Le niveau de gouvernance : pourquoi on construit, jusqu’où on investit, quels risques on accepte. C’est le niveau du Business Case, du Project Product Description, du plan. j’occupe ici trois casquettes simultanément : Executive / Sponsor (porteur de la justification business), Project Board (arbitrage des priorités et des jalons) et Project Manager (structure des phases et des revues). Quand je pense que la sécu. voulait que je sois patient expert en plus…

Le niveau de Delivery : comment on livre, par quels incréments, à quel rythme. C’est le niveau des sprints Scrum, des critères de done, des audits de livraison. Claude assure la maîtrise d’œuvre technique. Perplexity apporte la robustesse académique. Genspark matérialise visuellement. Merci pour ça du fond de ma cuisine

Prince2 Agile fait le lien entre les deux niveaux. En haut : des produits de management qui cadrent l’investissement et les risques, là c’est moins de 1000 euros pour l’année, ça va mais pour les risques, il y en a : conformité, anonymat, détournement de l’utilisation…  En bas : des produits opérationnels livrés par sprints et acceptés sur critères explicites. Merci à mes ami(e)s pour les bêta-tests qui ont permis de faire mes Revue du Sprint pas sous la forme attendu par le modèle mais dans le fond qui à produit les effets attendus.

Comment je suis devenu un Product Owner augmenté

La notion de PO augmenté formulée par Perplexity mérite d’être expliquée. Dans un projet Scrum standard le Product Owner gère un backlog et priorise des features :

• Définir clairement chaque élément de mon Product Backlog.
• Prioriser les éléments pour atteindre les objectifs du produit.
• Maximiser la valeur du travail de développement. réalisé par mes IA.
• Maintenir un backlog visible, transparent et facile à comprendre pour tous : ça je ne l’ai pas fait et je ne sais pas encore si je le regrette.
• S’assurer que mes IA « comprennent » chaque élément au bon niveau de détail. Là, c’est de l’orchestration et la route n’est pas toujours simple, mais elle se fait

Dans le projet ÉMERGENCE, je cumule ces fonctions avec en plus :

• La conception du cadre théorique : Rumelt, Star Model, TOM, sociologie des orga. (une remise à niveau de ce que j’avais étudié aux Arts et Métiers en développement des systèmes d’organisation) et  Nature Humaine (une passion toute personnelle pour les typologies de personnalité de longue date et enrichi de plus 1000 heures de formation en psychologie comportementale…)
• La validation des contenus rédactionnels sur la base de mes expériences terrain
• La décision commerciale (gratuit vs payant)
• La posture éthique : signaux faibles, seuil d’anonymat, posture marketing (Je ne vais quand même pas partager la souffrance des entreprises qui on besoin d’aide, ça serait vraiment un marketing de merde) et la part de nature humaine dans les interactions, les décisions.

Quand tu fais ça seul, t’es forcement cumulard, mais en fait c’est la conséquence naturelle d’un projet où la vision et l’expertise métier sont indissociables du produit construit. les Product Owner, sont des oiseaux de proie avec une vue perçante.

La structure du backlog

Perplexity propose d’organiser le backlog ÉMERGENCE en cinq EPICS cohérentes avec la logique du cadre :

Epic	Contenu	Statut
A — Diagnostic ÉMERGENCE	Questionnaires, scoring, archétypes, signaux	✅ Livré — 4 diagnostics + Audit 360°
B — Kernel Rumelt & narratif stratégique	Kernels types, narratifs par profil	✅ Intégré dans les rapports
C — Run vs Build Agile  et StarModel et Congruence	TOM RUN/BUILD, OD séquençage M0/M1	✅ Livré dans le Diagnostic TOM et OD
D — Contenus & Offre	Pages web, trames commerciales	🔄 En cours – Finalisation
E — Industrialisation & Data	n8n, base de données, benchmarks	📋 Backlog Sprint 9+

Ce cadrage rétrospectif confirme que le projet a suivi une logique cohérente même sans backlog formalisé au démarrage. Les cinq EPICS étaient implicitement présentes dans ma vision initiale. Elles se sont matérialisées dans l’ordre de leur dépendance logique et ma capacité a les concrétiser.

---

Mon rôle : ce que l’IA ne fait pas à ma place

La vision

Le cadre de l’ÉMERGENCE :  quatre diagnostics, une synthèse systémique, une posture, un modèle commercial gratuit/payant vient de mes vingt ans d’expérience terrain mais aussi du e-commerce ou de la générations de leads. Aucun outil IA n’aurait pu le concevoir sans cette expérience humaine. Elles ne peuvent pas savoir ce que vit un dirigeant de PME à 3h du matin quand sa trésorerie est tendue, que ses meilleurs collaborateurs commencent à regarder ailleurs et que l’administration le harcèle ; tu sais quand, au bord de la tombe, on vient te mettre le dernier coup de pelle dans la tête. (Merci Hanan pour cette belle métaphore)

La matière et l’expérience

Les trois symptômes de la page TOM,  « encore un coup de com », « excusez-moi vous auriez une minute », « on n’a pas les moyens de notre politique »,  viennent de mon vécu. En fait ils viennent tous de mon vécu en entreprise, de mots exacts, de bruits de couloirs, de réunions, de déjeuner d’affaires… Perplexity a vérifié qu’ils correspondaient aux patterns documentés dans la littérature sur les PME françaises. Je les ai apportés. Ensemble nous avons créé ses symptômes génériques mais qui parlent déjà à ceux qui les ont lu.

Les décisions

Chaque décision a été prise dans la conversation et validée avant construction. Pas de code écrit avant que le concept soit clarifié. Pas de CSV produit avant que la structure soit validée. Pas de page rédigée avant que la sémantique soit alignée. C’est moi qui ai dit oui ou non, pas les outils. Human-in-the-loop (HITL)

La posture

Ma posture est la même depuis bien longtemps : dire ce qui est et dire ce que ne sont pas les choses, dire non et dire les limites. Dans le cadre du projet, j’ai quand même demandé à Claude de prend le rôle de Scrum Master et ça a bien amélioré notre vélocité. Je reviendrai sur ce point dans un autre article.

La validation terrain

Le test complet à 10 répondants sur les trois diagnostics : Diagnostic Stratégique, TOM, OD, le scénario de test, les personas, le parcours complet, les corrections de bug . C’est le premier contact avec la réalité. Aucun outil IA ne peut faire ça tout seul. Ce test final avant la livraison de la release et d’un test dans une PMI.

---

La méthode Prince2 Agile en pratique

Le Business Case est resté valide

Au démarrage,  créer un cadre de diagnostic PME en self-service, gratuit en lead generation, payant en synthèse systémique. À l’arrivée : le Business Case s’est enrichi de l’Audit 360°, d’une synthèse pour moi que je génère à la demande de RDV avant appel. Enrichi mais pas dévié. Toujours anonyme.

C’est la définition d’un Business Case bien construit selon Prince2 : il cadre l’investissement ultra-léger sans rigidifier la direction. Chaque enrichissement a été évalué contre le Business Case initial avant d’être intégré et surtout en valeur client.

Les sprints ont produit des incréments utilisables

Pas des prototypes. Pas des maquettes. Du code déployable, des CSV importables, des interfaces fonctionnelles, des trames Word avec tags actifs, des corrections de bugs en phase de tests et de la productivité sans fatigue ; ça doit rester fun et participer à un mieux être physique.

Sprint	Livrable	Statut
Sprint 1	Diagnostic Stratégique Rumelt patché et déployé	✅
Sprint 2	Diagnostic TOM Hybride V1.0 complet	✅
Sprint 3	Diagnostic OD V1.0 complet	✅
Sprint 4	Architecture Audit 360° conçue et validée	✅
Sprint 5	Audit 360° V1.0 complet	✅
Sprint 6	Cinq pages web rédigées	✅
Sprint 7	Alignement sémantique et rétros	✅
Sprint 8	Congruence complète — en cours	🔄
Sprint 9	Automatisation n8n	📋
Sprint 10	Supports d’intervention client	📋

Les adaptations ont été intégrées sans déstabiliser

Cinq changements majeurs non prévus au démarrage. Tous intégrés en cours de route sans remettre en cause l’architecture existante.

1. Synthèse consultant distinct du rapport client
2. Signal comme outil de « protection commerciale »
3. Nuance managériale A/B/C/D dans l’OD
4. Audit 360° comme produit payant distinct
5. Rapport Lecture des Écarts comme cinquième livrable

C’est la définition d’un projet agile qui fonctionne ; modifier sans déstabiliser.

La qualité comme règle non négociable

Chaque livrable audité avant livraison. Chaque CSV relu ligne par ligne : zéro décalage de colonnes. Chaque code vérifié : zéro tag manquant. Chaque docx validé : zéro erreur structurelle.

La définition of Done s’est construite empiriquement en cours de projet et s’applique désormais à chaque livrable :

Done CSV

• Généré via csv.writer avec QUOTE_ALL
• Relu en relecture Python — 0 décalage de colonnes
• Toutes les clés obligatoires renseignées
• Copié dans /outputs

Done GAS

• Toutes les fonctions listées et auditées
• Tous les tags alignés avec le dictionnaire
• 0 tag manquant, 0 tag en trop
• Guard sur les clés CONFIG critiques

Done HTML

• Tous les steps identifiés
• Tous les appels GAS listés et minimisés
• 0 référence résiduelle au diagnostic précédent
• Checks fonctionnels spécifiques selon le diagnostic

Done DOCX

• Validé par validate.py — 0 erreur
• Tous les tags présents : audit croisé dictionnaire
• Structure sections conforme à la trame

Done Page web

• Hero aligné avec les verbes
• Blocs 1/2/3 cohérents avec le hero
• Ton validé : pas de jargon, pas de superlatifs
• FAQ couvre les vraies objections

---

Ce que le projet a produit en chiffres

En 8 mois de formation et de travail itératif à mon rythme dans le cadre du projet de re-mobilisation consolidation de la CRAMIF (oui ça existe…)

4   diagnostics complets et déployés  1   Audit 360° avec rapport systémique  9   fichiers GAS (~9 000 lignes de code)  4   interfaces HTML (~5 000 lignes)  30+ fichiers CSV (~400 colonnes, ~500 lignes de données)  6   trames Word (~800 paragraphes, ~300 tags)  5   pages web (~8 000 mots)  49  entrées de contenu rédactionnel pour le 360°  1   cadre conceptuel cohérent de l'intérieur

D’après ce que disent Le Claude et Le Perplexe, ce n’est pas une vélocité normale pour un consultant solo. C’est la vélocité d’un Product Owner qui sait ce qu’il veut, qui valide vite, et qui a orchestré les bons outils au bon endroit. Merci vous êtes sympa avec moi 🙂

---

Journal d’un Product Owner augmenté

Comment les sessions se passent

Pas de brief préparé la veille. Pas de cahier des charges formalisé. Une conviction sur ce qu’on allait construire ce jour-là et une capacité à décider dès que la question se posait. Je dis « on » parce qu’on l’a fait avec la techno d’aujourd’hui et que cette techno parle, répond mais reste aveugle ; elle ne voit pas. C’est un avantage, car vous progressez aussi en capacité de management.

Une session type : 

Le Daily Scrum (irrégulier, mais le temps n’existe pas chez les IA) : on a fait quoi « hier », on va faire quoi aujourd’hui. Ça s’entremêle mais ça fonctionne

Ouverture   — "On attaque les CSV de l'OD aujourd'hui"  Production  — livraison itérative, audit en temps réel  Décision    — "ça je valide / ça on reformule / ça on laisse pour plus tard"  Clôture     — livrable dans /outputs, prochaine étape posée  

Comme avec ces bestioles, tu peux enchainer des sprints, tu te fais UNE Retrospective de Sprint une fois ou deux par semaine et ça ne dure pas une plombe. Croyez-moi, elles te disent ce qu’elles ont à te dire c’est net mais jamais cruel et tu peux faire la même chose. Doucement l’effet human in the loop fait son effet.

Des décisions nécessaires

La synthèse consultant accessible uniquement via le menu Sheet

Trente secondes avant un appel,  pas une interface web. Pas de téléchargement exposé au client. Une décision technique qui dit quelque chose d’éthique : le consultant voit ce que le client ne voit pas. Et ça ne se discute pas dans l’interface.

La nuance managériale A/B/C/D dans l’OD

C’est la pièce la plus différenciante du Diagnostic Organisation Design. Elle n’était pas dans le scope initial. Elle est venue d’une question simple : deux organisations avec le même archétype structurel mais des styles de management différents : est-ce que le plan M0 est le même ? Non. Donc la nuance existe dans la réalité. Elle doit exister dans le diagnostic.

« Ce que ce diagnostic n’est pas » sur chaque page web

Une section qui dit les limites avant les promesses. Ce n’est pas un argument de vente, c’est une protection contre les mauvaises attentes. Et paradoxalement c’est ce qui construit le plus de confiance de mon point de vue.

La transparence sur les outils IA

Y compris cet article. Y compris ce bloc. La décision la plus simple et la plus cohérente du projet,  elle vient du même endroit que toutes les autres. Si je prêche la transparence alors je me l’applique et je la pratique. Congruence toujours.

Les décisions que j’aurais prises différemment

On est toujours plus savant en revenant de la source

Un backlog visible dès le départ

J’ai porté le concept du projet dans ma tête. Ça a fonctionné. Mais un Google Doc simple avec les items en cours, en attente et différés aurait économisé quelques minutes de remise en contexte à chaque session.

Un test utilisateur avant le sprint 3

J’aurais dû tester le Diagnostic TOM sur un vrai dirigeant avant de construire l’OD. Les insights du premier contact avec la réalité auraient peut-être changé certains choix de conception. C’est un risque assumé, pas une erreur de jugement. La différence est importante et ça pourra évoluer,

La question du paiement plus tôt

Identifiée comme hors scope trop rapidement. Elle méritait trente minutes de spike architectural au démarrage, pas pour décider du mécanisme, mais pour poser le principe. Au début c’était un exercice intellectuel thérapeutique, mais quand ça change, ça change, faut pas se dégonfler.

Les noms d’onglets documentés dès le premier diagnostic

L’incident SESSIONS/REGELS/CONFI sur le TOM aurait pu être évité par une checklist de déploiement livrée avec le premier diagnostic. Elle arrive au Sprint 8. Mieux vaut tard que jamais.

Les chiffres du Product Owner

Sessions de travail             : ~20  Décisions prises en session     : ~150  Décisions différées             : ~12  Décisions annulées/reformulées  : ~8  Taux de décision immédiate      : ~85%  Reformulations majeures         : 6    (archétypes OD, nuances managériales,     signal ROUGE, 360° payant,     Lecture des Écarts, sémantique heroes)  Moments "ça ne résonne pas"     : ~15    → reformulations qui ont toujours      produit quelque chose de meilleur

---

Ce que la cartographie Prince2 Agile / Scrum révèle rétrospectivement

Perplexity a produit cette analyse après coup, pas en temps réel. (Pour la validation par Simplon du bout de papier qui dit que je suis Scrum Version Française ou pas mais pour justifier l’utilisation de mon CPF – Merci aux auditeurs de ce matin qui ont acceptés que je leur présente ce vrai projet ; on se revoit pour la certif. ITIL). C’est une relecture de gouvernance d’un projet qui s’est construit de façon itérative et parfois implicite. Sa valeur est précisément dans cet écart : elle nomme ce qui s’est passé avec un vocabulaire de gouvernance que je n’utiliserais pas pour ce projet.

Les 3 observations méritent d’être retenues :

Le projet a respecté les principes Prince2 sans les appliquer formellement.

Justification business continue. Apprendre de l’expérience. Définir les rôles. Gérer par exception. Focaliser sur les produits. Adapter à l’environnement. Ces six principes Prince2 ont tous été présents, pas dans des documents, dans les décisions et les conversations. Apprendre de l’expérience est quelque chose de complètement intégré aux IA si tu le demande. Je me suis fait presque sermonner par ChatGPT que j’utilise presque jamais suite un prompt de feignant 🙂

Le backlog a été géré par la vision, pas par un outil.

Dans une équipe humaine classique un backlog non formalisé serait un risque de désorganisation. Dans ce projet la clarté de la vision du Product Owner a rendu le backlog formel inutile à court terme. C’est une condition rarement réunie et elle ne tient pas au-delà d’un certain volume de complexité. Les prochains sprints (n8n, supports client, paiement) justifieront probablement un backlog formalisé. J’ajoute que ce n’est pas probablement mais oui, je dois m’y contraindre.

La vélocité vient de la qualité des relations entre les membres de l’équipe.

Pas de la puissance des outils individuels. Chaque outil sur son registre. Chaque décision au bon niveau. Chaque livrable audité avant acceptation. C’est la définition Scrum d’une équipe auto-organisée et pluridisciplinaire, appliquée à une équipe dont les membres sont des IA et un sénior abimé mais dont le cerveau fonctionne à nouveau correctement.

---

Ce que j’ai appris en trois leçons transférables

L’IA amplifie l’expertise. Elle ne la remplace pas.

Un marteau entre les mains d’un menuisier expérimenté (mon papa était menuisier) produit des meubles. Entre les mains de quelqu’un qui ne sait pas ce qu’il fait il produit des accidents. Les outils IA fonctionnent selon le même principe. Ce qui a rendu ce projet possible c’est vingt ans d’expérience qui ont permis de valider chaque livrable en temps réel et aussi toutes les vraies formations en ligne sur le thème (oubliez les rigolos influenceurs). Sans cette expérience les outils auraient produit quelque chose de générique peut-être techniquement correct, certainement pas utile.

La décision reste humaine !

Sur ce projet environ 150 décisions structurantes ont été prises. Chacune par moi. L’outil proposait parfois plusieurs options avec leurs implications. Je choisissais. Parfois je reformulais. Parfois je disais « non on garde ça ». La vélocité vient de cette capacité à décider vite et bien pas de la puissance des outils.

La transparence est un avantage compétitif.

Cacher comment le travail a été produit aurait été plus confortable à court terme. Mais ça aurait contredit la posture ma posture « diagnostic honnête » sur chaque page. Donc pas d’impostures

---

Ce que ça dit sur les PME et pourquoi c’est dans ce blog

Ce projet est une démonstration grandeur nature de ce que le Cadre de l’ÉMERGENCE dit aux dirigeants et CoDir de PME.

Les bons outils au bon endroit libèrent de la capacité pour ce qui compte vraiment. Pas les meilleurs outils. Les bons, ceux qui correspondent à ce qu’on a besoin de faire, ni plus ni moins.

Une organisation bien conçue ne repose pas sur l’héroïsme de quelques individus et leur égo. Elle repose sur une architecture où chaque élément fait ce qu’il fait le mieux et se repose en confiance, sur les autres pour le reste.

La cohérence entre le dire et le faire est mesurable. C’est exactement ce que le Diagnostic Organisation Design mesure dans vos organisations. J’ai commencé par l’appliquer à moi même.

---

La suite : les prochains sprints

Le projet continue. Le test complet à 10 répondants est en cours. Il va révéler ce que la conception n’a pas pu prévoir.

🔴 Sprint 8 — Congruence complète     Alignement sémantique des 5 pages     Checklist déploiement Sheet OD et 360°     Templates Google Doc OD + 360°    🟡 Sprint 9 — Automatisation n8n     Workflows site web     Pipeline publication blog     Notifications sessions    🟡 Sprint 10 — Supports client     Trames de restitution diagnostics     Supports séminaire CODIR     Outils d'animation terrain    🟢 Sprint 11+ — Itérations terrain     Ajustements post-test     Calibration seuils CONFIG     Codes d'accès 360° payant     Mécanisme paiement

Et il y aura d’autres articles. Parce que ce qui se construit mérite d’être partagé, sans filtre et dans ce que je suis.

---

Une dernière chose

Ce projet m’a confirmé quelque chose que je savais intuitivement mais que je n’avais pas encore vécu à cette échelle ; là j’en ai conscience.

Un système bien conçu génère ses propres idées.

Le Cadre de l’ÉMERGENCE est cohérent de l’intérieur. Quand un cadre est cohérent de l’intérieur chaque nouvelle décision trouve naturellement sa place, elle n’a pas besoin d’être forcée. Les cinq enrichissements majeurs non prévus au démarrage ne sont pas des ajouts. Ce sont des émergences. Des conséquences naturelles d’un cadre posé. De la congruence de qui je suis et ce que je peux apporter dans mes limites. Être aligné, c’est ça la Gestalt appliquée à un projet. Le tout dit quelque chose que les parties ne disent pas.

Et c’est exactement ce que l’Audit 360° ÉMERGENCE fait pour vos organisations.

---

Jacky Malgras — Emergence – Boussole de Management
Paris 16ème | coesor.fr

---

Note de transparence

Cet article a été rédigé avec l’équipe IA du projet ÉMERGENCE :

• Claude (Anthropic) : LeadDev, Scrum Master, relecture et reformulations, architecture, facilitation
• Perplexity : recherche, cartographie Prince2 Agile / Scrum, analyse de gouvernance, vérifications de sources et plus encore…
• Genspark / Banana : Production visuelle (images et illustrations)
• n8n : automatisation à venir (Sprint 9)

Remerciements à SKILLS4ALL et toute l’équipe pour la qualité de leurs formations en ligne et l’approche de la formation, j’ai adoré et je reviens bientôt pour COBIT, ITIL et ISO27, à Chantalle SERVAIS (PNL), à Bernard Hevin (Coaching et +) et à de nombreux autres mentors…

La vision, les décisions, la matière terrain et la validation de chaque livrable sont de mon fait et je les assume. Les membres de cette équipe d’IA sont fiers d’y avoir contribué. (C’est les IA qui le disent)