3 façons d’utiliser les garde-fous pour progresser et vous adapter aux changements fréquents.

Les garde-fous sont un moyen utile de rester concentré sur vos objectifs et vous faire savoir si vous progressez.

Three Ways to Use Guardrails to Make Progress and Adapt to Frequent Change par Johanna Rothman

https://www.jrothman.com/newsletter/2026/08/three-ways-to-use-guardrails-to-make-progress-and-adapt-to-frequent-change/

Avez-vous l’impression d’être au milieu de changements trop fréquents ?

Oui. Même si je n’ai que des projets gérables et relativement petits, je n’arrive pas à prévoir les différents angles pour prédire ce que je dois faire et quand. Comme nous avons des changements fréquents, je dois souvent m’adapter aux nouvelles circonstances.

C’est encore pire pour mes clients, avec leurs efforts plus importants. Ils ont du mal à savoir quoi faire et quand capturer un segment de marché. Ou même à savoir ce que certains clients pourraient vouloir. Les managers veulent trop souvent changer de focus pour que les équipes puissent avoir le temps de répondre.

C’est une recette pour le désastre : ne pas savoir si les progrès jusqu’ici en valent la peine, ni même quoi planifier ensuite.

Changer trop souvent est un vrai casse-tête pour tout le monde.

Je trouve que les garde-fous sont un moyen utile de rester concentré sur mes objectifs et de me faire savoir si je progresse.

J’utilise les garde-fous de ces trois façons :

  1. Une orientation pour vous assurer que l’équipe commence bien le travail. Surtout en plein milieu de changements fréquents, nous devons savoir que nous avons le bon focus.
  2. Assurez-vous de ne pas trop avancer sur un « mauvais » chemin. Le changement peut nous désorienter, donc surveiller un « mauvais » chemin nous aide à voir où nous pourrions vouloir changer.
  3. Offrez un retour d’information si nous réalisons que nous ne progressons pas assez vite. Sommes-nous là où nous espérions être maintenant ? Sinon, quelles sont nos options ?

En prenant une équipe comme exemple, j’utilise les garde-fous pour mon travail exactement de la même manière.

Conseil 1 : Orientez-vous avec des garde-fous.

Quand j’ai déménagé dans la région de Boston, nous n’avions pas de GPS. À la place, nous avions besoin de cartes papier pour trouver notre chemin. De plus, la région de Boston présente plusieurs caractéristiques intéressantes sur ses autoroutes. Il est tout à fait possible d’être orienté vers le nord et d’être sur une autoroute appelée « Sud ». Oui, cela m’a embrouillée et cela embrouille encore les visiteurs de la région.

Cependant, j’ai utilisé ma capacité à lire une carte pour m’orienter et m’assurer de partir dans la bonne direction. Parce que la dernière chose que je voulais, c’était d’être dix kilomètres plus loin et de réaliser que j’allais dans la mauvaise direction. Pour cela, j’avais besoin de savoir quels garde-fous ou panneaux de signalisation chercher.

Bien que les projets et programmes ne soient certainement pas la même chose que de rouler sur de vieux chemins de campagne, nous pouvons utiliser l’idée d’orientation pour bien démarrer le projet ou le programme. J’aime m’assurer que nous connaissons suffisamment le projet ou le programme motivations, limites ou contraintes. Cela nous indiquera comment faire des compromis, surtout lorsque tout le monde a l’impression que le changement se produit plus vite que nous ne pouvons l’imaginer.

Conseil 2 : Attention aux panneaux de garde-fous.

En conduisant, on peut repérer des panneaux sur le bord de la route. J’aime bien les bornes kilométriques — tant que je sais si je compte de manière croissante ou décroissante. (C’est l’une des raisons pour lesquelles les cartes papier étaient si précieuses. Elles indiquaient au lecteur de cartes combien de kilomètres parcourus à quel moment du trajet.)

Encore une fois, les projets et programmes ne sont pas comme conduire. Cependant, nous pouvons évaluer les progrès avec des product backlog burnup charts. Ou bien, nous pouvons examiner le temps de cycle pour nous assurer que notre travail ne l’excède pas. En tant que manager de projet ou de programme, vous avez des options, comme demander aux gens de cartographier leur chaine de valeur (value stream). Cela indiquera à l’équipe s’ils doivent changer quelque chose dans leur travail, comme une collaboration accrue.

Et si votre équipe ressemblait à celle d’un de mes anciens clients ? Les seniors de l’équipe de 20 personnes disaient : « Nous ne collaborons pas. Nous travaillons seuls et cela nous plaît. Vous ne pouvez pas nous forcer à collaborer. »

J’ai répondu : « Non, et je ne vous demanderai absolument pas de collaborer. Cependant, si votre cycle est assez long et que vous ne pouvez pas progresser car chacun de vous ne passe pas assez de temps ensemble, vous pourriez choisir de collaborer. Dans ce cas, je vous conseillerai des façons qui pourraient vous convenir. »

L’équipe a décidé de revoir leur Carte des flux de valeur et leur Temps de cycle pour voir ce qui se passait. Après une semaine sans quasiment aucun progrès, les membres seniors de l’équipe ont demandé : « Quelles options recommandez-vous ? »

J’ai expliqué les concepts de pairing, swarming, and mobbing*.

Ils ont refusé le pairing et le mobbing, mais ont décidé qu’ils adoraient le Swarming. Comme l’équipe voyait ses données à travers leurs cartes de la chaîne de valeur et de temps de cycle, ils ont choisi comment travailler.

* Swarming (Essaim)

2 équipes. Les membres de l’équipe 1 se réunissent en équipe et discutent de l’élément (limite WIP de 1) avec le product owner. Ils discutent entre eux pendant quelques minutes pour décider de leur « plan d’attaque » (leurs mots) puis se dispersent. (L’équipe coopère, mais ne collabore pas tout le temps.) Les testeurs développent l’automatisation et prennent des notes sur les tests exploratoires. Les développeurs travaillent sur le code.

Dans l’équipe 2, des personnes sont associées, sur un seul clavier, pour le travail sur la plateforme/middleware. La personne de l’interface utilisateur travaille seule, vérifiant quand elle a terminé. Tout le monde enregistre son travail dans la base de code, au fur et à mesure qu’ils le terminent.

L’équipe 1 a un accord pour revenir toutes les 25 minutes afin de prendre des nouvelles les unes des autres. Ils font cela avec ce genre de rapport : « J’ai fini avec cette pièce. J’ai besoin d’aide pour la suite. Qui est disponible ? » Ou « J’ai fini autant que possible pour l’instant. Quelqu’un a besoin d’une autre paire d’yeux ? » (Note : vous voudrez peut-être plus ou moins de 25 minutes. Ils ont choisi ce moment parce qu’ils ont des histoires assez petites et veulent s’assurer de maintenir un rythme et un élan raisonnables.

À mesure que les gens terminent leur travail, ils aident les autres de toutes les manières possibles. Au début de l’agilité de l’équipe 1, ils avaient énormément de « dette technique » pour les tests automatisés. (Je dirais que c’est une automatisation insuffisante des tests, mais quel que soit le terme que vous voulez, ça me va.) Les développeurs ont terminé leurs histoires et aidé les testeurs à démarrer leur automatisation des tests.

* Mobbing

2 équipes. Toute l’équipe 1 est assise autour d’une table avec un seul clavier. La sortie du moniteur est envoyée à un projecteur pour que chacun voie ce que fait la personne qui tape. Cette équipe a une règle selon laquelle elle alterne le clavier toutes les 15 minutes. (Vous pourriez préférer un temps un peu plus long ou un peu plus court. D’après mon expérience, des temps plus courts sont mieux, mais c’est peut-être juste moi.) Parfois, c’est le testeur qui dirige, développant des tests automatisés. Parfois, c’est le développeur qui dirige. Cette équipe utilise souvent le TDD, donc les tests guident leur développement.

L’équipe 2 fait des vérifications au moins aussi souvent que l’on passe le clavier. Parfois, plus souvent.

Remarquez que le travail en cours (WIP) est petit, à un étage. Dans le swarming et le mobbing, les équipes travaillent sur une seule histoire. C’est tout. Leur objectif est de faire le travail qui permet de terminer cette histoire unique.

  • Pairing (Appariement)

L’appairage est un clavier, une machine, deux paires d’yeux. Le clavier est le conducteur, l’observateur est le navigateur. Vous bénéficiez d’une revue continue du travail au fur et à mesure. Je pose souvent ce que je considère comme des questions « stupides » quand je suis le navigateur. Parfois, les questions ne sont pas stupides — elles nous incitent en duo à mieux comprendre l’objet. Parfois, c’est le cas. Cela ne me dérange pas. Je trouve que lorsque je jumelle, j’apprends énormément sur le domaine.

Conseil 3 : Voyez comment les garde-fous peuvent offrir des retours d’informations, surtout avec des changements fréquents.

(Alors que ma métaphore de la conduite fonctionne pour les deux premiers conseils, elle ne marche pas pour celui-ci.)

Parfois, au milieu de changements fréquents, le progrès semble glissant. C’est ce sentiment de faire deux pas en avant, un pas en arrière.

Quand cela se produit, j’aime poser la question « combien peu ». Je pose cette question à propos de tout travail et à tous les niveaux :

  • Pouvons-nous réduire le nombre de projets que nous finançons à partir du portefeuille ? Si oui, pouvons-nous demander à davantage d’équipes de collaborer pour terminer ces projets moins nombreux plus rapidement ?
  • Quel minimum de fonctionnalités pouvons-nous livrer dans ce produit tout en satisfaisant notre client ? (Voir Considérez les options de produits avec des résultats minimaux pour plus de détails.)
  • Quelle part de cette équipe peut-elle faire et livrer quelque chose aussi propre que possible et rapidement pour manager ces changements fréquents ?

Nous nous habituons tellement à penser qu’il faut livrer « tout », ou « beaucoup de fonctionnalités », ou autre chose de grand, que nous ne réalisons pas toujours que nos clients pourraient vouloir quelque chose de plus petit.

Les équipes peuvent utiliser ces petites parties de travail pour livrer plus rapidement des garde-fous plus prévisibles.

L’équipe livrera-t-elle « tout » immédiatement ? Non. Et ce n’est souvent pas nécessaire.

Au contraire, lorsque les projets et programmes apportent de petits incréments de valeur, aussi souvent que possible, les personnes peuvent progresser et s’adapter à ces changements fréquents. Les garde-fous m’aident à faire cela, à gérer combien je planifie et quand. Ils peuvent aussi vous aider.

Pourquoi un bon projet peut devenir un mauvais investissement quand l’exécution et le timing ne suivent pas Par Khalid de DUBAIMMO

Un retour d’expérience depuis l’immobilier « off-plan » (Vente en l’État Futur d’Achèvement) à Dubaï.

Dans l’immobilier neuf à Dubaï, l’investisseur regarde souvent d’abord le produit : l’emplacement, le promoteur, le prix au mètre carré, le rendement attendu, le plan de paiement. C’est logique. Mais avec l’expérience, j’ai appris qu’un autre facteur peut être tout aussi déterminant : la qualité d’exécution du projet et le respect du calendrier annoncé.

Un projet peut être séduisant sur le papier et pourtant devenir un investissement médiocre si l’exécution dérive. À l’inverse, un projet moins spectaculaire mais bien piloté, livré dans des conditions cohérentes et avec une communication claire peut produire une expérience d’investissement beaucoup plus solide. Cette réalité immobilière rejoint directement les fondamentaux du management de projet :

La promesse initiale n’a de valeur que si l’organisation est capable de la transformer en résultat concret.

1. Le retard n’est pas seulement un problème de planning.

Quand un projet prend six, neuf ou douze mois de retard, on parle souvent simplement de « retard de livraison ». Pour l’investisseur, les conséquences sont pourtant beaucoup plus larges. Le capital reste immobilisé plus longtemps, les loyers attendus sont repoussés, un éventuel refinancement ou une revente doit être décalé, et le scénario patrimonial prévu au départ change.

Il faut donc regarder le calendrier comme une variable économique, pas seulement comme une date contractuelle. Deux projets affichant le même rendement théorique peuvent finalement produire des résultats très différents si l’un est livré à temps et l’autre beaucoup plus tard. La performance réelle dépend aussi du moment où l’actif devient effectivement exploitable.

Pour un manager de projet, c’est un rappel classique : un délai n’est jamais isolé.

Une dérive de planning se propage vers les coûts, les ressources, la satisfaction des parties prenantes et parfois même la qualité finale. Pour un investisseur, la logique est identique.

2. Ce qui compte, ce n’est pas seulement le plan initial, mais la capacité à absorber les écarts.

Aucun projet complexe ne se déroule exactement comme prévu. Dans la construction, les aléas peuvent venir des approvisionnements, des sous-traitants, des autorisations, des changements techniques ou de contraintes logistiques. Le sujet n’est donc pas de rechercher un projet « sans problème ». Il est de comprendre comment l’organisation réagit quand un problème apparaît.

Dans les projets que j’analyse, j’accorde beaucoup d’importance à trois signaux : la continuité réelle du chantier, la qualité de la communication et la capacité du promoteur à prendre des décisions rapidement. Un retard annoncé tôt, expliqué et accompagné d’un plan crédible n’a pas le même impact qu’un retard découvert progressivement à travers des réponses vagues ou contradictoires.

Cette différence est aussi valable dans n’importe quel projet d’entreprise. Les parties prenantes tolèrent souvent mieux un écart lorsqu’elles comprennent la situation, voient que les responsabilités sont prises et disposent d’une nouvelle trajectoire claire.

L’incertitude non gérée est généralement plus destructrice que le problème lui-même.

3. La coordination des parties prenantes devient visible au moment des difficultés.

Un projet immobilier réunit un grand nombre d’acteurs : promoteur, entreprise générale, sous-traitants, bureaux d’études, autorités, fournisseurs, équipes commerciales et clients. Tant que tout avance correctement, cette complexité reste relativement invisible. Elle devient évidente lorsque le projet rencontre une difficulté.

C’est souvent à ce moment-là que l’on mesure la maturité réelle de la gouvernance. Qui décide ? Qui informe ? Qui suit les engagements ? Les informations données par les équipes commerciales sont-elles alignées avec celles des équipes opérationnelles ? Les changements sont-ils documentés ?

Pour l’investisseur, ces éléments paraissent parfois secondaires au moment de l’achat. Pourtant, ils deviennent déterminants lorsque la livraison approche.

Pour le manager de projet, le parallèle est direct : une gouvernance claire, des responsabilités explicites et une circulation fiable de l’information sont des facteurs de performance autant que la compétence technique.

4. Un marché haussier peut masquer les erreurs d’exécution.

Pendant une phase de forte hausse immobilière, beaucoup d’erreurs restent invisibles. Un prix d’entrée trop élevé, une livraison tardive ou un produit moyen peuvent être compensés par l’appréciation générale du marché. L’investisseur peut même réaliser une plus-value malgré une sélection initiale imparfaite.

Lorsque le marché devient plus stable ou plus sélectif, ce mécanisme disparaît progressivement. La qualité du choix initial ressort alors beaucoup plus clairement. Le bon prix d’entrée, la solidité du promoteur, la cohérence du projet, la demande locative et la liquidité à la revente reprennent toute leur importance.

C’est une leçon intéressante pour le management de projet en général : un environnement favorable peut masquer une organisation fragile.

Lorsque les conditions se durcissent, ce sont les fondamentaux — gouvernance, exécution, discipline, gestion des risques — qui font la différence.

5. Ce que je recommande avant de considérer un projet comme « bon ».

Aujourd’hui, je ne considère plus un projet uniquement à travers son potentiel commercial. J’essaie de répondre à une question plus large : quelles conditions doivent être réunies pour que la promesse puisse réellement être exécutée ?

Cela suppose de regarder le prix d’entrée et le rendement, mais aussi l’historique du promoteur, sa capacité financière, la cohérence du calendrier, la structure du plan de paiement, l’état réel de l’avancement, la qualité des partenaires impliqués et le scénario de sortie de l’investisseur.

Cette approche ne permet pas d’éliminer tous les risques. Elle permet surtout de mieux les identifier avant de s’engager et d’éviter de confondre un bon produit avec un bon projet d’investissement.

Conclusion : l’exécution est une composante de la valeur.

Dans l’immobilier comme dans le management de projet, la valeur ne se crée pas au moment où la promesse est formulée. Elle se crée pendant l’exécution.

Un emplacement exceptionnel, un beau concept ou une projection financière attractive ne suffisent pas si le projet n’est pas capable de franchir correctement les étapes qui le séparent de sa livraison. À l’inverse, une exécution rigoureuse peut renforcer considérablement la valeur d’un projet initialement plus simple.

Pour l’investisseur, cela conduit à une règle très concrète : ne pas seulement demander « est-ce un bon projet ? », mais aussi « qui va l’exécuter, comment, avec quelle gouvernance, et que se passe-t-il si le planning dérive ? »

C’est souvent dans la réponse à ces questions que se trouve la différence entre une bonne présentation commerciale et un bon investissement.


À propos de l’auteur

Khalid dirige DUBAIMMO, cabinet spécialisé dans l’accompagnement des investisseurs francophones à Dubaï et Abu Dhabi. Son approche repose sur l’analyse du prix d’entrée, du rendement net plausible, de la qualité d’exécution des projets et du scénario de sortie avant toute recommandation. Il intervient au croisement de l’analyse immobilière, de la sélection de projets et de l’accompagnement opérationnel des investisseurs.
www.dubaimmo.com

Seriez-vous un « déployeur » sans le savoir ? par Jeremy Couchet

Chef de projet : vous êtes peut-être déjà « déployeur » au sens du règlement européen sur l’IA.

Imaginez un déploiement classique. Un projet CRM, un lot « modules complémentaires », et parmi eux un scoring de leads alimenté par apprentissage automatique, ou un assistant qui rédige les réponses clients. Pour le chef de projet, c’est un lot technique parmi d’autres : un périmètre, des tests, une recette, une mise en production.

Pour le règlement européen sur l’intelligence artificielle, ce même jalon est un acte juridique. Le jour de la mise en service, l’organisation devient « déployeur » d’un système d’IA, avec des obligations propres. Et personne ne l’a décidé explicitement : c’est arrivé dans le lot 3.

Fournisseur, déployeur : la distinction qui structure tout.

Le règlement (UE) 2024/1689 distingue deux rôles principaux. Le fournisseur conçoit ou fait développer le système et le met sur le marché : c’est l’éditeur de votre outil. Le déployeur, lui, utilise le système sous sa propre autorité dans le cadre de son activité : c’est votre organisation, dès que l’outil tourne pour de vrai.

La conséquence pratique est simple à retenir : vous n’avez pas besoin d’avoir construit quoi que ce soit pour avoir des obligations.

Intégrer, paramétrer et mettre en service suffit. Et comme l’IA arrive désormais embarquée dans les ERP, les CRM et les suites bureautiques, beaucoup d’organisations sont devenues déployeuses sans qu’aucune décision projet ne l’ait jamais formulé ainsi.

Ce que le règlement attend concrètement d’un déployeur.

Le niveau d’exigence dépend du niveau de risque du système. Deux obligations valent pour tous les usages : veiller à un usage éclairé de l’IA par les équipes, et respecter la transparence pour les contenus générés et les chatbots. Pour les systèmes à haut risque, le règlement va plus loin, et bonne nouvelle pour les chefs de projet : ces obligations ressemblent beaucoup à des livrables.

En langage projet :

  • Utiliser le système conformément à sa notice d’utilisation : la documentation éditeur devient une pièce de référence du projet, à collecter et à archiver.
  • Confier la supervision à des personnes compétentes : un rôle à nommer dans le RACI, avec la capacité réelle d’intervenir sur les sorties du système.
  • Veiller à la pertinence des données d’entrée quand le déployeur les maîtrise : un critère de recette de plus.
  • Surveiller le fonctionnement et signaler les incidents sérieux : la surveillance ne s’arrête pas à la garantie de bon fonctionnement technique.
  • Informer les personnes concernées lorsque le système les touche directement, salariés compris pour les usages RH.

Aucun de ces points n’exige un métier nouveau. Ce sont des exigences non fonctionnelles, du même ordre que la sécurité ou l’accessibilité : elles se planifient, s’assignent et se recettent. Et même quand le système n’est pas classé à haut risque, ces gestes restent la meilleure pratique disponible : ils coûtent peu pendant le projet et protègent longtemps après.

Le calendrier réel, sans dramatisation.

Depuisb, les pratiques interdites sont proscrites et chaque organisation doit veiller à un usage éclairé de l’IA par ses équipes. Depuis le 2 août 2026, les obligations de transparence s’appliquent : un chatbot en contact avec le public doit se signaler comme tel, et les contenus générés à caractère réaliste doivent être identifiables. Les obligations complètes pour les systèmes à haut risque listés en Annexe III s’appliqueront le 2 décembre 2027, après le report décidé à l’été 2026.

Ce délai sur le haut risque mérite une lecture d’ingénieur. Une documentation peut s’écrire tard. En revanche, la journalisation des décisions du système et la traçabilité de son fonctionnement se construisent avec le projet : une trace non enregistrée ne se recrée pas après coup. Si votre déploiement touche un domaine sensible, recrutement, notation, accès à des services essentiels, ces exigences se spécifient maintenant, dans le cahier des charges, pas en 2027.

Le réflexe à intégrer aux jalons

Vingt ans dans l’aéronautique m’ont appris une chose transposable ici : la conformité n’est pas une phase finale, c’est un attribut du livrable à chaque jalon. Personne ne certifie un avion à la fin ; chaque étape porte sa part de preuve.

Appliqué à un projet incluant de l’IA, cela tient en trois questions à poser à chaque revue :

  • Quel est notre rôle sur ce composant : fournisseur ou déployeur ?
  • Où se situe l’usage sur l’échelle de risque du règlement, et touche-t-il des personnes ?
  • Quelle échéance du calendrier le concerne, et qu’est-ce qui doit être conçu dès maintenant plutôt que rattrapé plus tard ?

Par où commencer lundi matin ?

Cinq gestes suffisent à mettre un projet du bon côté de la ligne, et aucun ne demande un budget :

  1. Inscrire le composant IA à l’inventaire des systèmes de l’organisation, avec son éditeur et sa fonction.
  2. Collecter la notice et la documentation de l’éditeur, et les verser au dossier projet.
  3. Nommer la personne chargée de la supervision humaine, et lui en donner les moyens.
  4. Poser par écrit à l’éditeur la question du marquage des contenus générés, et conserver sa réponse.
  5. Informer les utilisateurs et les personnes concernées de la présence et du rôle de l’IA dans le processus.

Le chef de projet est sans doute la personne la mieux placée de l’organisation pour cette tâche : il tient déjà le planning, les livrables et les parties prenantes.

Le règlement européen sur l’IA n’ajoute pas un métier à son portefeuille. Il ajoute une colonne à des tableaux qu’il maîtrise déjà.


Jeremy Couchet

Jeremy Couchet a passé vingt ans dans la maintenance aéronautique, un secteur où la conformité fait partie du travail quotidien.

Il est le fondateur de Complyla, qui accompagne les PME européennes et les cabinets de protection des données dans leur mise en conformité avec le règlement européen sur l’intelligence artificielle.

Le visage dangereux de la prudence…

Le principal danger dans la vie est que vous preniez trop de précautions. attribué à Alfred Adler

The Dangerous Face of Caution par Dan Rockwell

La prudence évalue les risques. Regardez bien des deux côtés avant de traverser la route. La prudence excessive ne quitte jamais le trottoir.

La prudence prépare. Une prudence excessive exige la perfection.

Le courage agit avec des informations incomplètes. La prudence excessive exige la certitude.

Une prudence excessive conduit à :

  • Des occasions manquées. Pendant que vous vous préparez, ceux qui ont du courage agissent.
  • Croissance retardée. Les zones de confort sont des pierres tombales.
  • Des équipes frustrées. Les gens perdent confiance en eux quand les leaders s’obsèdent sur les craintes.
  • Influence diminuée. Les suiveurs font confiance aux leaders qui agissent de manière responsable. Pas aux leaders qui évaluent sans fin.

Incertitude

Les plus grandes opportunités sont enveloppées d’incertitude.

L’innovation sans risque améliore le présent.

Le changement rencontre de la résistance.

Le courage exige de la vulnérabilité.

Choisissez le courage plutôt que l’autoprotection

Le leadership c’est agir en présence d’incertitude. Atteindre l’étape suivante suffit à progresser.

#1. Cessez de chercher de la sécurité.

Le but du leadership n’est pas d’éviter la défaite.

La prudence excessive est une protection de soi.

  • « Et si j’échoue ? »
  • « Et si les gens me critiquent ? »
  • « Et si j’ai l’air ridicule ? »

Essayez-vous de réussir ou d’éviter l’échec ?

#2. Acceptez l’imperfection.

Agissez avant d’être prêt.

Arrêtez d’attendre la certitude, la confiance et de meilleures conditions.

La peur de l’imperfection est surmontée par la participation.

L’engagement génère de la croissance.

#3. Mettez l’accent sur la contribution.

Privilégiez la contribution au confort.

« Comment suis-je ? » mène à l’autoprotection.

« Comment puis-je aider ? » inspire le courage.

Le service détourne l’attention de l’autoprotection.

#4. Agissez « Comme si ».

La peur se fait passer pour une protection.

  • Si vous n’essayez jamais, vous ne pouvez pas échouer.
  • Si vous ne postulez jamais, vous ne pouvez pas être refusé.
  • Si vous ne parlez jamais, vous ne pouvez pas être critiqué.

Si vous aviez déjà du courage, que feriez-vous ?

Faites-le.

L’action engendre la confiance.

Faites confiance à votre capacité à vous élever.

Quelle idée dans ce billet vous parle-t-elle le plus ?

Retours d’expérience sur DantotsuPM – Les 3 billets les plus appréciés du premier semestre 2026.

Voici les 3 retours d’expérience les plus appréciés du premier semestre 2026.

Le management de projet gère l’exécution, mais qui gouverne la décision ? par Walter Afonso Filho

Comment mettre en place une structure de management de projet pour de petites équipes ?

« Faites le pont entre les flux de travail cliniques et la prestation Agile » par Sohail Bashir Chughtai

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2 et AgilePM.

Comment percevez-vous votre adaptabilité et votre résilience lorsque vous prenez des décisions ?

Comment l’adaptabilité et la résilience fonctionnent-elles ensemble ?

How Can You See Your Adaptability and Resilience as You Make Decisions? par Johanna Rothman

https://createadaptablelife.com/2026/03/how-can-you-see-your-adaptability-and-resilience-as-you-make-decisions.html

Comment décidez-vous de la suite ?

La plupart d’entre nous trouvent assez tentant de continuer ce que nous avons toujours fait jusqu’à présent. Pour continuer, nous n’avons pas besoin de beaucoup d’adaptabilité ni de résilience. Mais que faites-vous quand quelque chose se passe ?

Ce quelque chose peut être merveilleux, comme un événement du cycle de vie, ou lorsque vous organisez un grand rassemblement entre amis et/ou famille.

Ou que quelque chose pourrait être grave, comme perdre votre emploi.

Quand quelque chose se passe, nous avons souvent besoin de notre capacité d’adaptation et de résilience pour réagir. Pourtant, trop peu d’entre nous réalisent comment nous pouvons utiliser cette adaptabilité et cette résilience.

L’image ci-dessus montre les axes que j’utilise pour évaluer mon adaptabilité et ma résilience dans ma prise de décisions. Ou, quand je réalise que je dois choisir à nouveau.

Comment l’adaptabilité et la résilience fonctionnent-elles ensemble ?

Voici une autre image que j’utilise pour tester mon adaptabilité et ma résilience :

Parfois, je m’entends me dire : « J’ai toujours fait comme ça. »

Je sais que je n’utilise pas toutes mes compétences. Au lieu de cela, je suis un peu coincée dans le quadrant inférieur gauche de faible adaptabilité et de faible résilience.

Comparez cela avec le fait de monter dans le quadrant supérieur gauche. Quand vous pouvez dire que vous avez besoin d’alternatives, ou que vous vous demandez ce qu’il faut faire maintenant — c’est ainsi que vous utilisez votre résilience, même si vous êtes incertains.

Ensuite, il y a le quadrant inférieur droit, où l’adaptabilité est plus faible, mais la résilience est plus élevée. Vous comprenez la nécessité de changer, mais vous essayez de contenir ce changement. C’est pourquoi j’ai mis « Planifiez le travail et travaillez sur le plan » dans ce quadrant.

Enfin, vous avez le quadrant supérieur droit, avec le plus d’adaptabilité et de résilience. Comment pouvez-vous expérimenter ? À quelle vitesse pouvez-vous apprendre ? Par où pourriez-vous commencer ?

Permettez-moi de parler de ceci dans le contexte de la prise de décision, car c’est là où je veux aller cette semaine.

Toutes les décisions reflètent l’adaptabilité et la résilience — ou leur absence.

Chaque décision est différente et nécessite des degrés variables d’adaptabilité et de résilience.

Imaginez organiser un dîner pour quatre à huit personnes. Vous avez le menu puis vous allez au magasin pour acheter tous les ingrédients. Mais le magasin ne propose pas l’ingrédient clé, comme les asperges. Si vous êtes à ma place, vous vous réjouissez de l’absence d’asperges, et optez pour un autre légume vert. Ou alors, vous décidez d’acheter un plat préparé auprès d’un traiteur. Ou vous recréez tout le menu, cette fois sans asperges.

Mais si ce dîner était pour douze personnes ? Ou trente ? Maintenant, vous avez un problème de taille et vous devrez peut-être repenser toutes les décisions. Cela dit, c’est une décision relativement simple avec de nombreuses options évidentes.

Certaines décisions offrent beaucoup moins d’options évidentes. L’une d’elles est de manager le portefeuille de projets, que ce soit pour vous-mêmes ou pour votre organisation. C’est parce que vous devez choisir ce qu’on ne fera pas, ce à quoi dire non.

Choisissez tôt pour maximiser adaptabilité et résilience.

Nous pourrions reporter ces décisions au « dernier moment responsable ». Quand sera ce « dernier » moment ? Souvent, il arrive bien plus tôt que ce que l’on réalise. Par exemple, si l’entreprise perd de l’argent, prenez des décisions dès maintenant et commencez à expérimenter les possibilités de générer des revenus. Plus l’entreprise attend le « dernier » moment responsable, plus ce « dernier » moment arrive souvent bien trop tard.

Au lieu de choisir autre chose, ils décident de « continuer », de « garder le cap ». Cette décision de « continuer » est une conséquence d’une faible adaptabilité et d’une faible résilience.

C’est pourquoi des prises de décision précoces et fréquentes, même pour de petites décisions, peut aider lorsque vous avez de grandes décisions à prendre. Plus vous pratiquez votre adaptabilité et votre résilience dans les petites décisions, plus il vous est facile de les appliquer aux grandes décisions.

La première étape, comme toujours, est de voir votre réalité pour voir comment vous décidez.

C’est la question cette semaine :

Comment pouvez-vous percevoir votre adaptabilité et votre résilience lorsque vous prenez des décisions ?

Réduire le temps d’attente dans les hôpitaux par Sohail Bashir Chughtai

Une perspective pratique utilisant le diagramme en arête de poisson (Fishbone ou Ishikawa Diagram) et la pensée PMI.

Dans de nombreux hôpitaux, les longs délais d’attente sont discrètement devenus une partie de la routine quotidienne.

Un patient arrive à l’heure pour un rendez-vous prévu, mais finit par attendre 45 minutes, parfois plus d’une heure. Au fil du temps, cela commence à affecter non seulement la satisfaction des patients, mais aussi la confiance dans le système.

D’un point de vue opérationnel et management de projet, ce n’est pas seulement une question de planning. C’est un problème de processus, impliquant plusieurs parties prenantes, des flux de travail et des dépendances dans le système.

Le vrai défi n’est pas de réaliser l’existence de retards. Le défi est de comprendre pourquoi ils existent de façon récurrente.

Pourquoi l’analyse des causes profondes est-elle nécessaire ?

Dans les milieux hospitaliers, il est très facile de tirer des conclusions hâtives :

  • Le docteur est en retard.
  • Trop de patients sont programmés.
  • Le système est lent.

Cependant, lorsque le même problème se répète chaque jour, cela indique généralement quelque chose de plus profond.

C’est là que l’analyse de la cause profonde (Root Cause Analysis / RCA) devient importante. Au lieu de réagir aux symptômes, RCA se concentre sur l’identification des causes sous-jacentes du problème.

L’un des outils les plus pratiques pour cela est le diagramme en arête de poisson (diagramme d’Ishikawa).

Qu’est-ce qu’un diagramme en arête de poisson ?

Un diagramme en arête de poisson est une méthode simple mais structurée pour analyser un problème en le décomposant en catégories de causes possibles.

Vous commencez par un énoncé clair du problème, par exemple : « Le temps d’attente pour un rendez-vous en Consultation Externe dépasse les limites acceptables. »

Ensuite, vous explorez les causes dans des domaines clés tels que :

  • Personnes
  • Processus
  • Technologie
  • Environnement
  • Management

Le but n’est pas de blâmer les individus, mais de comprendre comment différents facteurs se combinent pour créer le problème.

Pourquoi utiliser le diagramme en arête de poisson dans les opérations hospitalières ?

Les hôpitaux sont des systèmes complexes. Un délai provient rarement d’une seule source.

Sans approche structurée :

  • Les équipes ont tendance à blâmer les individus.
  • Des solutions temporaires sont appliquées.
  • Le même problème continue.

L’utilisation d’une approche Fishbone aide les équipes :

  • Regardez le système de bout en bout.
  • Impliquez plusieurs parties prenantes.
  • Passez des hypothèses aux causes réelles.
  • Alignez les discussions sur les faits plutôt que sur les opinions.

Du point de vue du PMI®, cela soutient directement :

  • Gestion de la qualité (identification des causes racines).
  • Engagement des parties prenantes.
  • Amélioration continue.
  • Identification des risques.

Comprendre les retards dans la pratique

Quand on applique la pensée Fishbone aux retards de rendez-vous, le tableau devient plus clair.

Personnes

Les retards sont souvent attribués aux médecins, mais en réalité :

  • Certains patients nécessitent plus de temps de consultation.
  • Le personnel n‘a pas préparé les patients avant la consultation.
  • La réception peut surbooker sans prendre en compte la variabilité des durées.

Exemple :
Un consultant programme 30 patients avec des créneaux de 10 minutes. Quelques consultations complexes nécessitent chacune 20 minutes. Le retard s’accumule et affecte l’ensemble du planning.

Processus

Les écarts de processus sont généralement les facteurs les plus importants :

  • Créneaux horaires fixes malgré des besoins de consultation de durées variables.
  • Patients sans rendez-vous ajoutés sans contrôle.
  • Pas de flux de travail pré-consultation.

Exemple :
Un patient entre dans la salle de consultation, et ce n’est qu’ensuite que les constantes sont prises et que son historique est discuté. Cela augmente inutilement le temps passé par patient avec le médecin.

Technologie

La technologie peut soit améliorer, soit ralentir les opérations :

  • Système de gestion des dossiers médicaux lent.
  • Trop de documentation manuelle.
  • Manque d’une planification intelligente.

Exemple :
2 minutes supplémentaires par patient pour la documentation entraînent près d’une heure de retard sur 30 patients.

Environnement

L’installation physique joue également un rôle :

  • Centres d’intervention surpeuplés.
  • Mauvaise conception du flux patient.
  • Goulots d’étranglement à l’enregistrement ou à la capture des constantes vitales.
Management

Souvent négligé mais essentiel :

  • Pas de KPIs définis pour le temps d’attente.
  • Manque de contrôle.
  • Aucun mécanisme de responsabilité.

Sans mesure, l’amélioration est difficile à maintenir.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMP® et bien d’autres.

Passez de l’analyse à l’action.

Une fois les causes profondes clairement identifiées, les solutions deviennent plus pratiques et ciblées.

Parmi les améliorations efficaces, on trouve :

  • Planification différenciée (nouveaux patients vs patients de suivi).
  • Flux de travail avant consultation (antécédents et constantes pris avant la visite chez le médecin).
  • Systèmes de visibilité des files d’attente (affichage des jetons, alertes SMS).
  • Optimisation du système de gestion des dossiers médicaux (modèles, réduction de la saisie manuelle).
  • Des KPIs et des tableaux de bord définis pour surveiller le temps d’attente.

Ces changements ne sont pas complexes individuellement, mais pris ensemble, ils améliorent significativement le flux opérationnel.

Un résultat pratique.

Dans un scénario, le temps d’attente moyen est passé de plus d’une heure à moins de 15 minutes après la mise en œuvre de changements structurés basés sur RCA.

La différence clé ne résidait pas uniquement dans la technologie. C’était la compréhension du système dans son ensemble.

Les retards à l’hôpital sont rarement causés par un seul facteur.

Ils résultent de multiples éléments interconnectés entre les personnes, les processus et les systèmes.

Le diagramme en arête de poisson offre un moyen pratique et structuré de découvrir ces connexions.

Du point de vue du management de projet, cela permet de déplacer l’attention de la résolution réactive de problèmes vers l‘amélioration au niveau du système, en accord avec les principes PMI de qualité, d’engagement des parties prenantes et de contrôle continu.

Dans le secteur de la santé, l’efficacité ne se limite pas à la rapidité. Il s’agit de concevoir des systèmes qui respectent à la fois les flux de travail cliniques et l’expérience du patient.


À propos de l’auteur

Sohail Bashir Chughtai

Sohail Bashir Chughtai, PMP®, est chef de projet informatique dans le domaine de la santé avec plus de 12 ans d’expérience à la tête d’initiatives de transformation numérique dans des milieux hospitaliers. Il est spécialisé dans la mise en œuvre de DME/DES (Dossiers Médicaux Electroniques et Dossiers de Santé Electroniques) , la prestation Agile dans les systèmes de santé réglementés, l’optimisation des flux de travail cliniques et les plateformes de santé numérique d’entreprise.

Il a dirigé des équipes interfonctionnelles produisant des modules d’urgence, d’hospitalisation, d’infirmières et de facturation numérique dans des écosystèmes de santé complexes, alignant la stratégie technologique avec les opérations cliniques réelles.

En élargissant actuellement son engagement professionnel à travers l’Europe, Sohail est ouvert à la collaboration et aux opportunités de leadership dans la transformation informatique de la santé, la stratégie de santé numérique et le management de projets d’entreprise sur le marché européen.

 

Maniaques du contrôle : pourquoi la poigne la plus serrée est-elle celle qui perd souvent le plus ?

Le contrôle, au-delà d’un certain point, produit le chaos qu’il est justement censé empêcher.

Control Freaks: Why the Tightest Grip Often Loses the Most par Bob Marshall

https://flowchainsensei.wordpress.com/2026/02/15/control-freaks-why-the-tightest-grip-often-loses-the-most/

Il existe un type particulier d’anxiété qui hante les organisations qui développent des logiciels. Cela se manifeste par des chaînes d’approbation sans fin, des demandes pour des demandes, des commissions de revue d’architecture qui se réunissent trimestriellement, et des processus de déploiement si baroques qu’ils nécessitent leur propre équipe de documentation.

Cela vient d’un endroit raisonnable. Le logiciel est invisible jusqu’à ce qu’il tombe en panne, et quand il tombe en panne, il le fait coûteusement. Alors nous cherchons à contrôler.

Le problème, c’est que le contrôle, au-delà d’un certain point, produit le chaos qu’il est justement censé empêcher.

L’illusion de sécurité

J’ai travaillé avec une équipe qui demandait sept approbations pour déployer un seul changement en ligne. La logique était irréprochable : plus d’yeux signifiait moins d’erreurs. En pratique, cela signifiait que les déploiements étaient regroupés en livraisons massives et peu fréquentes, chacune étant une terrifiante partie de roulette russe. Quand quelque chose se cassait, personne ne savait lequel des quarante changements en était la cause.

Pendant ce temps, une équipe au bout du couloir mettait en production des dizaines de fois par jour sans aucune validation. Leur secret n’était pas l’imprudence. C’était un investissement dans les tests automatisés, les feature flags* et le retour en arrière instantané. Ils avaient remplacé la surveillance humaine par la résilience systémique.

*feature flags – Les indicateurs de fonctionnalités (également appelés commutateurs ou interrupteurs de fonctionnalités) sont des morceaux de code logique if/else utilisés pour activer ou désactiver des fonctionnalités. Ils peuvent être activés ou désactivés manuellement ou lorsque certaines conditions sont remplies.

La première équipe se sentait en sécurité. La deuxième équipe était en sécurité.

Le contrôle comme symptôme

Lorsque vous constatez un contrôle excessif dans une organisation, vous observez un symptôme plutôt qu’une solution. Creusez sous la surface et vous trouverez :

  • Peur du blâme. Dans les cultures où l’échec est puni, les gens construisent des forteresses bureaucratiques. Chaque approbation est une responsabilité répartie. Si quelque chose tourne mal, au moins sept personnes l’ont approuvé.
  • Manque de confiance. Le micro-management est un problème de confiance caché sous des processus. Si vous faites confiance à vos ingénieurs, vous leur donnez des garde-fous et de l’autonomie. Sinon, vous leur donnez des listes de contrôle et de la surveillance.
  • Absence de boucles de rétroaction. Les mécanismes de contrôle se multiplient lorsque les organisations ne peuvent pas savoir si leur logiciel fonctionne réellement. Si vous disposez d’une surveillance robuste, d’alertes et d’un retour en arrière rapide, vous n’avez pas besoin qu’un comité approuve un changement de couleur de bouton.

Le paradoxe du couplage serré

L’architecture logicielle reflète la psychologie organisationnelle. Les équipes orientées contrôle construisent des systèmes orientés contrôle : des monolithes où chaque changement nécessite une coordination entre des dizaines de composants, des bases de données partagées qui rendent impossible un déploiement indépendant, des flux de travail d’approbation encodés dans le logiciel lui-même.

Ces systèmes semblent gérables car tout est visible et centralisé. Mais ils sont fragiles. Un point de défaillance unique devient un point unique de paralysie. L’organisation qui voulait le contrôle finit par être contrôlée par sa propre architecture.

L’alternative n’est pas le chaos : c’est un découplage réfléchi.

De petits services indépendants. Des contrats clairs. Des équipes qui livrent sans attendre l’autorisation de six autres équipes. Cela implique de renoncer au confort de tout savoir, et d’accepter que les systèmes distribués sont intrinsèquement plus difficiles à comprendre. Mais ce découplage échange un faux contrôle contre une vraie résilience.

À quoi ressemble un contrôle sain ?

Rien de tout cela ne signifie que le contrôle est mauvais. Les systèmes incontrôlés sont terrifiants à leur manière : codage de cowboy, bases de données de production accessibles aux stagiaires, déploiements qui ont lieu quand quelqu’un en ressent l’envie.

La distinction se situe entre contrôler les personnes et contrôler les résultats.

Les organisations saines s’obsèdent sur ce dernier :

  • Nous contrôlons la fiabilité en investissant dans la surveillance et la réponse aux incidents, et non en exigeant des tests manuels à chaque déploiement.
  • Nous contrôlons la sécurité en intégrant des mesures sécurisées par défaut sur nos plateformes, et non en obligeant les développeurs à remplir des questionnaires de sécurité qu’ils ne comprennent pas.
  • Nous contrôlons la qualité en recrutant bien, en fournissant un contexte clair et en créant des boucles de rétroaction rapides, pas en instituant une revue de code par des personnes très éloignées du travail.

Le but est de rendre la bonne chose facile et la mauvaise difficile. C’est un problème de conception, pas de permissions.

Lâcher prise

La partie la plus difficile pour réparer une culture obsédée par le contrôle, c’est qu’il faut que les personnes en contrôle l’abandonnent. C’est vraiment difficile à demander. Le contrôle est apaisant. L’autonomie — pour les autres — est stressante.

Mais voilà le truc : vous n’avez jamais vraiment eu le contrôle de toute façon. Vous aviez une apparence de contrôle, maintenu à un coût énorme en vitesse, en moral, et en l’attrition silencieuse de vos meilleurs éléments (qui partaient vers des endroits où on leur faisait confiance). Les réunions, les signatures, les commissions de revue, c’étaient un rituel, pas une sécurité.

La vraie sécurité vient des systèmes qui supposent que la panne va survenir et qui s’en remettent en douceur. D’équipes qui expérimentent sans permission et apprennent sans être blâmées. Des architectures qui se plient au lieu de se briser.

La poigne la plus ferme ne vous protège pas. Elle fatigue juste vos mains.

Les meilleures cultures d’ingénierie partagent un trait commun : elles sont obsédées par les résultats et décontractées quant aux méthodes. Elles précisent ce qui doit être vrai — le système doit être fiable, sécurisé, maintenable — puis s’écartent. Quand on explique aux gens intelligents à quoi ressemble le succès et qu’on leur donne les outils pour y parvenir, ils le font.

Le management de projet gère l’exécution, mais qui gouverne la décision ? par Walter Afonso Filho

Les échecs majeurs des projets proviennent rarement de la couche exécution. Ils prennent naissance bien avant dans la couche décisionnelle.

Depuis des décennies, les cadres de travail pour le management de projets aident les organisations à planifier, coordonner et exécuter des initiatives complexes. Des projets de construction au développement logiciel et aux programmes aérospatiaux, les méthodologies structurées ont amélioré la planification, l’allocation des ressources et la discipline de la distribution.

Pourtant, une question fondamentale reste largement sans réponse.

Qui gouverne les décisions qui façonnent le projet lui-même ?

Les cadres de travail de management de projets sont extrêmement efficaces pour gérer l’exécution. Ils définissent les tâches, responsabilités, étapes et livrables. Ils fournissent des outils pour suivre la progression, manager les risques et coordonner les équipes.

Mais les échecs majeurs des projets proviennent rarement de la couche exécution.

Ils prennent naissance bien avant dans la couche décisionnelle.

Les projets s’effondrent dans la décision avant de s’effondrer dans leur exécution.

L’exécution ne fait souvent que révéler des faiblesses déjà présentes dans le processus décisionnel. Lorsque l’on examine les échecs majeurs de projets dans plusieurs secteurs, un schéma récurrent apparaît : le projet était déjà structurellement fragile bien avant l’apparition du premier problème opérationnel.

Des décisions cruciales ont pu être prises :

  1. Avec des preuves incomplètes ou ambiguës.
  2. Sous forte pression organisationnelle.
  3. Au sein de structures de gouvernance fragiles.
  4. Dans des conditions d’irréversibilité où revenir sur la décision devient extrêmement difficile.

En d’autres termes, les projets n’échouent pas uniquement parce que l’exécution tourne mal.

Ils échouent parce que l’environnement décisionnel lui-même était instable.

Cette observation révèle une distinction rarement explicite dans la littérature traditionnelle sur le management de projet.

Le management de projet régit la manière dont les projets sont exécutés.

Mais les systèmes complexes exigent aussi une gouvernance sur la manière dont les décisions cruciales sont prises.

C’est le domaine de ce que j’appelle la gouvernance décisionnelle.

La gouvernance décisionnelle se concentre sur les conditions structurelles dans lesquelles les décisions sont prises au sein de systèmes complexes. Au lieu d’analyser uniquement les échéanciers, budgets ou livrables, elle examine l’environnement institutionnel entourant le processus décisionnel lui-même.

Différentes questions émergent :

  • Les décisions sont-elles étayées par des preuves suffisantes ?
  • Les responsabilités sont-elles clairement définies ?
  • Des engagements irréversibles sont-ils pris trop tôt ?
  • Les signaux d’alerte sont-ils ignorés ou supprimés ?
  • Les mécanismes de gouvernance sont-ils suffisamment robustes pour remettre en question les décisions ?

Dans les systèmes d’ingénierie complexes, les programmes aérospatiaux, les projets d’infrastructure ou les grandes plateformes numériques, les réponses à ces questions déterminent souvent la stabilité à long terme du système.

L’exécution peut être bien gérée alors que le régime décisionnel reste structurellement fragile.

Lorsque cela se produit, les organisations peuvent continuer à progresser vers la mise en œuvre même si les conditions de décision sous-jacentes se détériorent.

Le résultat est une forme d’accumulation invisible du risque.

Pour explorer ces dynamiques, j’ai développé un cadre conceptuel modélisant l’environnement décisionnel à travers des vecteurs structurels tels que la densité de la décision, l’irréversibilité, la disponibilité des preuves, la fragilité de la gouvernance et les signaux non résolus. Ensemble, ces facteurs contribuent à décrire la stabilité du régime décisionnel entourant un projet.

Cette perspective ne remplace pas le management de projet.

Au contraire, elle le complète.

Le management de projet garantit que le travail est organisé et exécuté efficacement. La gouvernance décisionnelle garantit que les décisions qui guident ce travail sont structurellement solides.

À mesure que les projets deviennent technologiquement plus complexes et organisationnellement interconnectés, l’importance de gouverner le processus décisionnel lui-même continuera de croître.

L’exécution compte.

Mais dans les systèmes complexes, les décisions comptent encore plus.


Walter Afonso Filho

Walter Afonso Filho

Walter Afonso Filho est ingénieur civil et mécanique, titulaire d’un MBA et de plus de 30 ans d’expérience dans des environnements d’ingénierie complexes, des organisations axées sur la technologie et des systèmes critiques pour la décision.

Il est le fondateur de l’IVEXSI Institute — www.ivexsi.org International Decision Governance Authority, une institution indépendante dédiée à la promotion de la gouvernance décisionnelle en ingénierie comme discipline formelle. Ses travaux portent sur la gouvernance des décisions techniques critiques, irréversibles et à fort impact, abordant l’autorité décisionnelle, la responsabilité, l’incertitude et la responsabilité institutionnelle au-delà des cadres traditionnels de management de projet et de conformité.

Tout au long de sa carrière, Walter a travaillé avec des multinationales telles que Philips, Ericsson, Tetra Pak et Embraer, contribuant à des projets à l’intersection de l’ingénierie, du risque, des systèmes de qualité et de la prise de décision organisationnelle.

Il possède une vaste expérience en audit, gestion de la qualité (y compris ISO 9000) et formation technique, ayant exercé en tant qu’auditeur principal, instructeur et coordinateur des programmes de gouvernance et de qualité dans les secteurs public et privé.

Walter a également créé et animé deux programmes nationaux de télévision au Brésil — *Qualidade Empresarial* (TV Bandeirantes) et *Empresa do Futuro* (Rede Vida) — axés sur la prise de décision exécutive, l’innovation et la responsabilité organisationnelle.

Il est l’auteur d’ouvrages à orientation internationale sur la gouvernance décisionnelle, notamment : « Decision Governance in Complex Projects and Systems ».

Le pouvoir de la perspective : Comment contrôler les défis de votre vie ?

La perspective est tout quand vous affrontez les challenges de la vie.

The Power of Perspective: How to Keep Life’s Challenges in Check par Steve Keating

https://stevekeating.me/2025/09/28/the-power-of-perspective-how-to-keep-lifes-challenges-in-check/

Parfois, nous sommes tellement débordés que tout semble nous irriter. Une critique sévère au travail, une prise de bec avec un ami, une interminable liste de choses à faire, soudainement, vous pouvez avoir l’impression que votre monde est en train de s’effondrer. Mais la vérité est que la plupart de ce qui nous stresse ne sont que de petites pièces d’un puzzle beaucoup plus grand et plus complexe.

Apprendre à garder les choses en perspective ne signifie pas ignorer les problèmes ; Il s’agit de développer un état d’esprit qui empêche les petits revers de vous ôter votre bien-être général.

Je crois fermement qu’il faut vivre dans ce que Dale Carnegie a appelé les « compartiments étanches ». Vivre chaque jour dans les limites de ses propres 24 heures. Cela signifie qu’il ne faut pas laisser les « choses » d’hier avoir un impact sur les efforts d’aujourd’hui. Il faut ne pas trop s’inquiéter des événements de demain au détriment du bonheur et de la productivité d’aujourd’hui.

Vivre dans des compartiments étanches est le superpouvoir qui vous permet de naviguer dans les tempêtes sans couler tout votre navire.

Voici quelques stratégies pratiques que vous pouvez utiliser pour faire un zoom arrière et reprendre pied lorsque la vie vous semble trop chargée et que votre compartiment étanche commence à prendre un peu l’eau.

#1 – La règle du 10/10/10

Lorsque vous faites face à une décision stressante ou à un bouleversement majeur, essayez de vous poser ces 3 questions simples :

  1. Comment vais-je me sentir à ce sujet dans 10 minutes ? (Impact immédiat)
  2. Comment vais-je me sentir à ce sujet dans 10 mois ? (Impact à moyen terme)
  3. Comment me sentirai-je à ce sujet dans 10 ans ? (Impact à long terme)

La plupart des choses qui causent une détresse immédiate – ce courriel gênant, un café renversé, une échéance non respectée – n’auront aucun poids émotionnel dans 10 mois ou 10 ans. Cet exercice déplace instantanément votre attention du drame actuel vers la réalité à long terme, réduisant souvent le problème à sa taille réelle et gérable.

#2 – La vérification du « pire scénario »

Nos esprits sont passés maîtres dans l’art du catastrophisme. Lorsque nous nous sentons anxieux, nous passons souvent directement aux résultats potentiels les plus dramatiques et les plus effrayants sans vérifier les faits.

La prochaine fois que vous sentirez une inquiétude monter en flèche, prenez un moment pour définir le pire des scénarios. Écrivez-le.

Ensuite, posez-vous deux autres questions :

  • Quelle est la probabilité que cela se produise ? (Soyez honnête, n’ayez pas peur.)
  • Si c’était le cas, quel serait le minimum absolu que je pourrais faire pour me rétablir ?

En affrontant le « pire » et en créant un plan de repli, vous lui enlevez son pouvoir. Vous vous rendez compte que même si le pire se produisait, tout irait bien et vous avez l’ingéniosité nécessaire pour y faire face. Vous passez de la panique à la planification. Cela vous enlèvera une tonne de poids des épaules.

#3 – Embrassez le « cercle d’inquiétude ou cercle d’influence »

Ce concept, popularisé par Stephen Covey, est essentiel pour réduire le stress lié à des choses que vous ne pouvez pas contrôler.

Cercle d’inquiétude

Tout ce qui vous inquiète : L’économie, la météo, ce que les autres pensent de vous, la mauvaise humeur d’un collègue.

Cercle d’influence

Les choses sur lesquelles vous pouvez réellement faire quelque chose : Vos efforts, votre attitude, vos limites et la façon dont vous utilisez votre temps.

Lorsque le stress frappe, identifiez quelle partie du problème tombe dans votre cercle d’influence. Ne gaspillez pas d’énergie à vous inquiéter de la météo (inquiétude) ; concentrez-vous sur prendre un parapluie (influence).

En consacrant votre temps et votre énergie uniquement à ce que vous pouvez contrôler, vous devenez plus efficace et moins surchargé.

#4 – Pratiquez la gratitude quotidiennement

Cela semble presque idiot, mais une pratique cohérente de gratitude est l’un des outils les plus puissants pour prendre du recul. Lorsque vous vous concentrez sur ce qui vous manque ou ce qui n’a pas fonctionné, vous rétrécissez votre vision. La gratitude vous oblige à l’élargir.

Prenez 3 minutes chaque matin ou soir pour énumérer 3 choses spécifiques pour lesquelles vous êtes vraiment reconnaissant. Il peut s’agir de votre café du matin, d’une bonne nuit de sommeil ou du soutien d’un ami.

Ce simple geste vous rappelle que même dans un mauvais jour, votre vie est remplie de bonnes choses réelles – et le petit revers auquel vous êtes actuellement confronté n’invalide aucune d’entre elles. Cela place vos problèmes dans un contexte plus riche et plus complet, ce qui a tendance à les réduire.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Une dernière réflexion : Vous êtes plus que vos problèmes.

N’oubliez pas que vous n’êtes pas votre situation immédiate. L’espoir, c’est la compréhension que vos circonstances actuelles sont très peu susceptibles d’être vos circonstances permanentes. Une mauvaise journée est un seul point de données, pas une image complète de votre vie. Cela signifie que vous avez toujours de l’espoir. Lorsque vous vous sentez piégé par un défi actuel, prenez du recul, respirez et utilisez l’un de ces outils pour faire un zoom arrière.

La capacité de garder les choses en perspective n’est pas un trait de caractère avec lequel vous êtes né ; C’est une compétence que vous développez, jour après jour, inquiétude après inquiétude. Commencez à vous entraîner dès aujourd’hui et observez à quel point vos défis deviennent plus petits et plus faciles à gérer.

La nature des pièges (et nombreux sont ceux tendus aux managers de projets…)

Notre culture est remplie de pièges fabriqués par l’homme, de situations qui valent la peine d’être évitées.

The nature of traps par Seth Godin

https://seths.blog/2024/11/the-nature-of-traps/

Ces pièges comportent trois éléments :

  1. Ils sont séduisants. Les pièges offrent un bénéfice et ils facilitent votre entrée.
  2. Il est difficile d’en sortir. Changer d’avis ne suffit pas.
  3. Quelqu’un d’autre en bénéficie davantage que vous.

En raison du troisième élément, l’organisateur ou les bénéficiaires d’un piège peuvent dépenser du temps et de l’argent pour le rendre toujours plus séduisant et pour dissimuler la nature de ce à quoi vous vous engagez réellement. Ils ont une vision à long terme, et les humains, en particulier les humains dans une impasse, ont tendance à ne rechercher que le soulagement à court terme qu’offre un piège.

Commencez par identifier les pièges qui sont tendus aux autres, des pièges qu’ils ne voient pas mais que vous apprenez à remarquer. Bientôt, vous commencerez à voir les pièges qui vous sont tendus.

« Projets et Cybersécurité », le nouveau livre blanc du PMI® France.

Les risques numériques engendrent d’autres menaces, bien souvent elles-mêmes à l’origine de nouveaux risques, auxquels l’organisation doit faire face.

La cybersécurité est devenue ces dernières années une préoccupation majeure des organisations de toutes tailles. Omniprésent, le numérique a pris une dimension fondamentale dans la société et dans la stratégie de nos organisations.

C’est pour cette raison que PMI France a décidé de lancer une série de Livres Blancs autour du thème « Projets et Cybersécurité ».

Ils traitent naturellement de l’intégration de la sécurité dans les projets.

  • L’écosystème de la Cybersécurité que doit absolument connaître le Chef de Projet.
  • La gouvernance qui porte la responsabilité des risques numériques et des moyens pour y répondre.
  • Les directions Métiers qui identifient les risques à travers une démarche d’intégration de la sécurité dans les projets.
  • Les experts techniques avec une vision transversale du risque « technique-métier-sectoriel ».

C’est un livre blanc particulièrement en phase avec l’actualité qui aborde un défi crucial auquel doivent faire face les différentes organisations.

Ce Livre Blanc de PMI-France, écrit en collaboration avec le Clusif, explore :

  • Les liens entre Gestion de Projet et Sécurité de l’Information.
  • Comment la sécurité et la protection de la donnée doivent être pensées en amont du projet et en quoi une bonne approche de gestion de projet favorise la mise en place d’une cybersécurité pertinente et efficace au sein de votre organisation.
  • Il a été réalisé avec la participation des salariés des entreprises suivantes : Orange, Allianz, Schneider Electric, Université Paris-Dauphine, AEGE (association des élèves de l’Ecole de Guerre Electronique), Effective Yellow, Effitek, Tersedia.

Ce périmètre est très vaste et nous avons fait le choix de nous concentrer dans ce premier ouvrage sur l’écosystème et la gouvernance de la Sécurité de l’Information.

Une fois ce socle posé, nous aborderons les autres points dans les Livres Blancs ultérieurs.

L’intégralité de ce livre blanc est accessible aux adhérents du PMI France. Connectez-vous et aller dans la rubrique « ressources » pour le télécharger.

Ce livre blanc, comme les autres publications du Cercle des Entreprises, représente un précieux retour d’expérience pour tout professionnel du projet soucieux d’éviter les écueils classiques et d’optimiser ses chances de succès.

Une initiative du PMI France menée par Lionel Bourceret et François Delignette

PMI is a registered mark of Project Management Institute, Inc.

Qu’est-ce que la « risque attitude » ?

Qu’est-ce que la « risque attitude » ?

What is Risk Attitude?

https://projectriskcoach.com/risk-attitude/ par Harry Hall

Dans ce billet, testons votre compréhension de ce qu’est « l’attitude face au risque ». Nous explorerons également différentes attitudes à l’égard du risque et la façon dont elles peuvent influer sur l’évaluation des risques.

Les managers de projet doivent chercher à comprendre les attitudes des principales parties prenantes à l’égard du risque pour les raisons suivantes :

  1. Les personnes à la recherche de risques l’emportent sur les parties prenantes peu enclines à prendre des risques, ce qui entraîne des risques plus élevés que ce qui est approprié.
  2. Les attitudes à l’égard du risque peuvent introduire des biais et nuire à l’évaluation des risques identifiés.
  3. Les attitudes négatives à l’égard du risque peuvent réduire la motivation d’une équipe de projet.
  4. L’attitude à l’égard du risque définit les types de risques que les parties prenantes sont prêtes à prendre.

Examen PMI-RMP ==> Réponse : B

Les gens ont des perceptions différentes des risques.

Une personne qui a une aversion pour le risque évaluera probablement les risques différemment d’une personne qui recherche les risques. L’intervenant peu enclin à prendre des risques a une faible tolérance aux risques et peut considérer les risques comme plus importants qu’ils ne le sont en réalité. D’autre part, la personne à la recherche de risques a une tolérance plus élevée aux risques et peut sous-estimer la gravité des risques.

Par conséquent, il est essentiel que les managers de projet comprennent et équilibrent les biais qui découlent des attitudes face au risque.

Qu’est-ce que l’attitude face au risque ?

« L’attitude à l’égard du risque est une disposition à l’incertitude, adoptée explicitement ou implicitement par des individus et des groupes, motivée par la perception et mise en évidence par un comportement observable. »  The Standard for Risk Management in Portfolios, Programs, and Projects.

Gamme d’attitudes à l’égard du risque

Les individus, les groupes ou les organisations peuvent avoir un large éventail d’attitudes à l’égard du risque. À une extrémité du spectre, certains peuvent être extrêmement réticents à prendre des risques et se concentrer principalement sur l’intervention (parfois excessive) envers les menaces du projet. À l’autre extrémité du spectre, les gens peuvent voir l’équation risque-récompense comme une opportunité passionnante de faire avancer un projet. Et ces parties prenantes peuvent être disposées à exposer le projet à un niveau de risque excessif (au-delà de la tolérance au risque définie). Au centre, nous voyons des parties prenantes neutres au risque.

Exemple : Adoption d’un nouveau logiciel de gestion de projet

Un chef de projet décide s’il doit adopter un nouveau logiciel de gestion de projet qui pourrait améliorer la collaboration d’équipe.

  • Attitude de recherche de risque :
     « Allons-y. Même s’il y a 50 % de chances que le logiciel ne s’intègre pas à nos systèmes existants, s’il fonctionne, nous gagnerons beaucoup de temps et aurons l’air innovants. »
  • Attitude réticente au risque :
    « Je ne veux pas prendre de risque. Le risque de perturber notre flux de travail actuel l’emporte sur les avantages potentiels. »
  • Attitude neutre au risque :
    « Je vais peser la probabilité de succès par rapport à l’impact potentiel. Si les avantages attendus sont supérieurs aux risques, alors j’irai de l’avant. »

Ainsi, l’attitude face au risque est essentiellement la prédisposition de l’organisation ou de l’individu à l’égard du risque, qu’il ait tendance à l’éviter, à l’accepter ou à le rechercher.

Et vous ?

Tenez-vous compte de l’attitude à l’égard du risque de vos principales parties prenantes ?

Et cherchez-vous à gérer les biais qui peuvent découler des attitudes à l’égard du risque ?

Lorsque vous lancez vos projets, interrogez vos principales parties prenantes. Au cours des entretiens, assurez-vous de poser des questions approfondies pour déterminer si cette personne est réticente au risque, neutre en matière de risque ou à la recherche du risque. Qu’est-ce qui motive sa perspective ?

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMP® et PMI-RMP®.

Si vous envisagez de passer la certification du PMI® Risk Management Professional (PMI-RMP®), voici de quoi vous aider à réussir.

PMI-RMP® Practice Exam est là pour vous aider à vous préparer en toute confiance. Il s’agit d’un excellent premier pas vers la certification, avec un nombre illimité de passages et de retours d’information intégrés.

Le PMI Risk Management Professional (PMI-RMP®)  Practice Exam est le seul officiellement approuvé par PMI et aligné sur le contenu de l’examen. Développé en collaboration avec des professionnels certifiés du management des risques, cet outil d’autoformation vous aide à évaluer vos connaissances et à suivre vos progrès tout en vous préparant pour le jour de l’examen.

Vous pouvez passer les tests aussi souvent que vous le souhaitez. Chaque question comprend une explication détaillée pour étayer votre apprentissage et approfondir votre compréhension des concepts clés du management des risques.

Vous aurez une idée plus claire des sujets abordés lors de l’examen et de l’orientation de votre évaluation. Avec des explications fournies pour chaque réponse, vous développerez une compréhension plus profonde et entrerez dans l’examen avec plus de clarté et de confiance.

“PMI”, the PMI logo, “PMI-RMP” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMP® et PMI-RMP®.

Comment exploiter et améliorer les opportunités dans votre projet ?

Ne managez pas que les risques négatifs, faites en sorte que les opportunités fonctionnent en votre faveur.

How To Exploit and Enhance Project Opportunities par Harry Hall

https://projectriskcoach.com/how-to-exploit-and-enhance-project-opportunities/

Imaginez un chef de projet qui se concentre principalement sur l’identification et le management des menaces du projet et très peu sur les opportunités. Cet état d’esprit unilatéral peut être coûteux. Les meilleurs chefs de projet savent exploiter et valoriser les opportunités.

Qu’est-ce qu’une opportunité de projet ?

Le dictionnaire Merriam-Webster définit l’opportunité comme « un ensemble de circonstances qui rendent possible l’action ».

En voici quelques exemples :

  • J’ai saisi l’occasion de rencontrer d’autres chefs de projet lors d’une réunion de mon chapitre PMI.
  • Une manager de projet a découvert que plusieurs parties prenantes clés travaillant à distance seront sur place pour une session de formation. Elle a pu planifier une réunion d’une heure pour discuter avec elles des principaux risques du projet.
  • Un analyste d’affaires a découvert un cours gratuit en ligne sur l’amélioration des processus. Le cours couvre les techniques de capture des exigences agiles que l’équipe de projet essaie d’adopter.

Que signifie « exploiter une opportunité de projet » ?

Lorsque nous exploitons une opportunité, nous faisons en sorte d’accroitre les chances que le risque se matérialise.

Supposons que vous ayez besoin de 40 ordinateurs portables pour un projet. Le coût des ordinateurs portables dépasse le montant budgété. Vous découvrez que si vous commandez 50 ordinateurs portables, vous bénéficierez d’une réduction de 10 %. Vous découvrez qu’un autre manager a besoin de 20 ordinateurs portables pour un projet distinct. La commande est passée, vous assurant une remise de 10 %.

Que signifie « améliorer une opportunité de projet » ?

Lorsque nous améliorons une opportunité, nous augmentons sa probabilité et/ou son impact.

L’équipe de projet travaillait sur un projet depuis trois mois et il restait cinq mois de travail. Le sponsor du projet a demandé au manager de projet de livrer le projet quatre semaines plus tôt que prévu.

Le manager de projet a découvert qu’un développeur qualifié et un testeur senior seraient disponibles dans un mois lorsqu’un autre projet serait clôturé. L’ajout de ces ressources supplémentaires aux deux tâches sur le chemin critique pourrait améliorer la probabilité de livrer le projet dans les délais requis.

Voyez-vous la différence entre exploiter et améliorer les opportunités ?

Faites en sorte que les opportunités fonctionnent en votre faveur.

De nombreuses personnes ont tendance à se concentrer davantage sur les risques négatifs que sur les risques positifs. C’est regrettable, car vous risquez de louper des occasions en or. Les personnes ou les organisations qui souhaitent exploiter et améliorer leurs opportunités doivent être intentionnelles.

Comment pouvez-vous y parvenir ?

  1. Soyez clair sur vos objectifs et pourquoi ils sont importants.
  2. Réunissez les parties prenantes concernées et réfléchissez aux opportunités.
  3. Capturez et évaluez les opportunités. Quelles opportunités ont la plus grande probabilité et le plus d’impact ?
  4. Identifiez les responsables des risques et des opportunités qui élaboreront et mettront en œuvre des plans d’intervention pour les opportunités les plus importantes.
  5. Élaborez et exécutez vos plans de réponse aux risques.
  6. Contrôlez les opportunités.

Comment identifier les risques d’un projet (Best of #10)

7 façons d’identifier les risques d’un projet par Harry Hall

90% de tous les risques peuvent être éliminés ou considérablement réduits grâce à une gestion de base des risques.

7 façons d’identifier les risques d’un projet

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes dont PMP® et PMI-RMP®.

A propos d’exiger une certitude…

Exiger la certitude serait-il une approche pour ne surtout rien changer ?

Demanding certainty par Seth Godin

https://seths.blog/2024/04/demanding-certainty/

Les défenseurs du statu quo exigent souvent des certitudes lorsqu’ils sont confrontés à des décisions concernant l’avenir.

Elle met en place les conditions pour ne rien faire, car la certitude n’arrive jamais avant la venue de l’avenir.

Il est beaucoup plus utile d’examiner les probabilités.

Lancer une pièce de monnaie en l’air donne 50 % de chances qu’elle retombe sur face. C’est un pari risqué.

Par contre, il y a plus de 95 % de chances que le niveau de la mer à Miami soit nettement plus élevé dans dix ans. Le pari inverse est-il celui que vous voulez prendre ?

Dès que nous pouvons commencer à discuter des probabilités, nous pouvons nous asseoir du même côté de la table et affiner nos estimations et nos profils de risque.

Mais la certitude ? La certitude est un autre mot pour retarder.

Faites face à l’incertitude et aidez les autres à faire de même !

S’il est un métier dans lequel l’incertitude est reine, c’est bien celui de manager de projet dont l’un des rôles majeurs est précisément de réduire l’incertitude !

Aucune de nos certitudes ne tient à l’épreuve du temps et des changements. Seul le changement est constant. Vos certitudes actuelles ne le sont pas. Préparez-vous à cette certitude !

En effet, l’incertitude domine actualités et conversations depuis des mois, dérèglement climatique, incendies à répétition en Amérique du Nord, guerres en Ukraine, entre Israël et le Hamas et depuis peu avec l’Iran qui pourraient dégénérer en conflits mondiaux…

Il y a de grandes incertitudes qui vont impacter vos approvisionnements et accroître vos coûts.

Vous êtes confrontés à des situations inconnues et nouvelles auxquelles personne n’a de réponse définitive. Vous ne semblez plus être maitres de votre destin et vous sentez peut-être stressés, anxieux voire épuisés.

Certains comportements peuvent vous aider à faire face à ces incertitudes.

Soyez davantage flexibles. Soyez ouverts à de nouvelles façons de travailler. Testez ces approches et apprenez en pratiquant.

Identifiez ce qui a changé. Qu’y-a-t-il de nouveau ? Qu’ est-ce qui s’est arrêté ? Et surtout,  qu’êtes-vous maintenant capables de faire ?

Décomposez chaque changement en petits composants plus petits et plus clairs sur lesquels vous pourrez réellement agir.

Soyez encore plus curieux. Générez de nouvelles idées. Considérez les alternatives et autres possibilités en questionnant ouvertement les options (« et si vous faisiez ceci ou cela ? »).

Développez ces comportements et apprenez aux autres à faire de même.

Cessez de vouloir dire aux personnes qui vous entourent ce qu’elles devraient faire ou penser. Vous ne pouvez pas dicter d’approches figées alors que le monde est en perpétuel mouvement accéléré. Formez plutôt ces personnes à penser, à explorer et à s’adapter par elles-mêmes en permanence.

La partie la plus difficile en premier (ou pas ?).

J’ai eu l’occasion de pratiquer dans mes projets les 2 approches, commencer par la partie la plus ardue ou bien par de plus faciles pour construire la confiance et engranger de premiers bénéfices.

Les 2 ont marché ou pas pour moi en fonction des projets (contenu, degré d’innovation, niveau de changement nécessaire dans les process et habitudes, durée…) et surtout des membres de l’équipe projet, de la gouvernance projet et des parties prenantes.

The hard part first par Seth Godin

https://seths.blog/2023/11/the-hard-part-first/

Si vous essayez de réduire les risques, faites d’abord la partie la plus difficile. De cette façon, en cas d’échec, vous aurez minimisé votre temps et vos efforts.

Mais, d’un autre côté, si vous recherchez l’adhésion et l’engagement afin de pouvoir traverser la partie difficile, faites-la en dernier.

Les gens ont extrêmement de mal à ignorer les coûts irrécupérables, et les victoires précoces et les sentiments d’identification qui découlent des succès faciles du début vous donneront de l’élan dans votre progression.


Alors, s’attaquer à la partie la plus difficile en premier ou plus tard ?

Comme je l’indiquais en intro, je n’ai pas de réponse universelle à cette question. J’apprécie l’approche Agile, en particulier Scrum, qui focalise les choix sur les éléments qui vont apporter le plus de bénéfices business en premier.

Et vous, quelles sont vos expériences sur ce sujet ?
CertYou est partenaire de DantotsuPM, allez voir toutes les certifications Agiles.

Gestion de l’innovation. Et si le succès était une question de méthode ? par Frédéric Sauzet

Savez-vous vraiment gérer l’incertitude dans vos projets innovants ?

Dans un monde où l’innovation est devenue le maître-mot de toute stratégie d’entreprise, nombreux sont ceux qui se heurtent à la réalité du terrain : comment gérer concrètement ces projets qui, par nature, échappent aux cadres traditionnels de la gestion ?

Pourquoi les méthodes classiques échouent-elles face à l’innovation ?

La gestion de projet nous a appris à décomposer un objectif final en sous-objectifs clairs, à anticiper les tâches et à contrôler rigoureusement l’avancement selon le fameux trio coût-qualité-délai. Cette approche, parfaitement adaptée aux environnements stables et prévisibles, se révèle pourtant inadaptée face aux défis de l’innovation véritable.

L’innovation nous place dans une situation fondamentalement différente : Comment concevoir et distribuer un produit sur un marché qui n’existe pas encore ? Comment évaluer la rentabilité d’une solution qui rompt avec l’offre actuelle ?

Sans repères stables et connus, la méthode classique aboutit généralement à 2 impasses.
  1. Soit elle conduit à l’abandon du projet innovant, incapable de satisfaire aux conditions initiales de coût-qualité-délai.
  2. Soit elle empêche même le démarrage de l’innovation, notamment lorsque les calculs de VAN (Valeur Actuelle Nette) affichent inévitablement des résultats négatifs.

L’innovation : Une exploration, pas une exécution.

Contrairement à un projet classique, l’innovation ne consiste pas à converger vers un objectif prédéfini. Il s’agit plutôt d’explorer des territoires inconnus, d’acquérir de l’information pour obtenir des résultats provisoires et, si nécessaire, bifurquer vers de nouvelles pistes.

Nous ne sommes plus dans un contexte de risque calculable, mais bien d’incertitude véritable. Et c’est précisément cette incertitude qui nous fait peur. Comme l’explique Anne Dufourmantelle dans son « Éloge du risque » :

L’incertitude est ce que nous craignons le plus. Toute notre organisation consiste à bloquer l’imprévu.

Le management de l’innovation : un cadre pour apprivoiser l’incertitude

Combien de fois ai-je vu des équipes brillantes s’essouffler sur des projets d’innovation qui ne décollaient jamais ?

Combien d’entreprises sont menacées par de nouveaux acteurs ou des technologies disruptives ?

La vérité est brutale :Les équipes planchent sur des idées, des prototypes sont développés, parfois même testés… mais très peu atteignent le marché. Encore moins contribuent significativement au chiffre d’affaires.

Et ce constat n’est pas marginal. Le baromètre McKinsey 2021 sur l’innovation révèle que 84 % des dirigeants considèrent l’innovation comme essentielle à leur stratégie, mais seuls 6 % se disent satisfaits de la performance de leur département innovation.

Alors pourquoi ce fossé abyssal entre intention stratégique et impact réel ? Et surtout, comment passer de l’idée au revenu ?

Des méthodes concrètes pour réussir vos projets d’innovation

Le livre sur Amazon

Ces observations m’ont poussé à écrire Le management de l’innovation en pratique, désormais publié par Afnor Editions.

Ce livre est né d’une conviction profonde : Transformer vos idées en succès durables n’est pas une question de chance, mais de méthode. J’y partage comment activer les véritables leviers générateurs de valeur, mobiliser vos équipes autour d’une vision qui inspire et explorer sereinement de nouveaux territoires d’activité.

Vous voulez transformer vos défis d’aujourd’hui en valeur pour demain ?

Commencez par le diagnostic innovation 360° d’innovecteur.

—

Frédéric Sauzet

Frédéric Sauzet

Fort de plus de 20 ans d’expérience dans les secteurs technologiques, industriels et commerciaux, Frédéric Sauzet a occupé les fonctions de Directeur Général de PlanetWatch et de Responsable d’InnoGEX, incubateur labellisé CERN. Il aide les organisations à transformer leurs idées innovantes en résultats tangibles. https://innovecteur.com/

Son dernier livre : Management de l’innovation en pratique avec l’ISO 56001