S'abonner maintenant

Quand on n’y prend pas garde, les métriques de conformité deviennent un véritable piège : des métriques pastèque.

Le Scrum Master devient alors un Scrum Manager et perd toute crédibilité auprès des personnes qu’il est censé accompagner.

Dans ce nouvel épisode, je vais tenter d’aller plus loin et expliquer pourquoi, malgré leur succès, les métriques de conformité tuent toute initiative de changement sur le long terme.

Et je vais te donner 5 situations dans lesquelles elles sévissent.

N’hésite pas à laisser ton avis dans les commentaires après l’écoute !

C’était Bruno pour te servir,

Tchô ! 😏

Abonnez-vous maintenant

En ce mois de juillet, trois nouvelles ressources sont disponibles dans la bibliothèque de l’Agile Radiator.

Lean Software Development - Mary et Tom Poppendieck

Le livre Lean Sofware Development de Mary et Tom Poppendieck adapte les principes du Lean Manufacturing au développement logiciel en montrant comment éliminer les gaspillages, accélérer les flux de livraison et maximiser la valeur apportée au client. Il s'articule autour de sept principes fondamentaux (éliminer le gaspillage, amplifier l'apprentissage, décider le plus tard possible, livrer le plus vite possible, responsabiliser les équipes, intégrer la qualité et optimiser l'ensemble) pour construire des organisations plus performantes et plus adaptatives.

A retrouver dans la section “Lean”

Inspired: How to Create Tech Products Customers Love - Marty Cagan

Le livre Inspired: How to Create Tech Products Customers Love de Marty Cagan explique comment les meilleures entreprises conçoivent des produits en s'appuyant sur des équipes produit autonomes, pluridisciplinaires et centrées sur les besoins réels des utilisateurs. Il met l'accent sur la découverte produit (Product Discovery), l'expérimentation rapide et la validation continue des idées afin de réduire les risques avant le développement et de maximiser les chances de créer des produits que les clients adoptent réellement.

A retrouver dans la section “Product Management”

The Nature of Software Development- Ron Jeffries

Le livre The Nature of Software Development de Ron Jeffries montre que le succès d’un projet logiciel repose avant tout sur la livraison fréquente de valeur métier, les retours rapides des utilisateurs et l’amélioration continue, plutôt que sur le respect rigide d’un processus. Il défend une approche pragmatique où les équipes réduisent les risques grâce à de petits incréments, une forte collaboration, des tests automatisés et une capacité permanente à s’adapter au changement.

A retrouver dans la section “Agilité”

NEWSLETTER

L’Agilité : Genèse, Partie 1

C’était comment, une transformation Agile à l’ancienne ?

A lire ici

NEWSLETTER

Le casse-tête prévisibilité et prévisions

Et pourquoi cela dépasse la simple différence sémantique en entreprise

A lire ici

Nouveau code d’accès à la librairie (valable un mois) :

AgileRadiator2310

Et n’hésite pas à proposer tes ressources gratuites dans la section “Envoyer sa ressource”.

Accès à l’Agile Radiator =>> ICI !

C’était Bruno pour te servir, bel été ☀️

Tchô ! ☺️

S'abonner maintenant

— Bruno, est-ce que tu peux nous dire si tu as déjà rencontré des managers qui t’ont demandé de chiffrer un projet agile ?

— Oh, bien sûr. Et ils avaient [toujours] des dates fixes qui ne pouvaient être repoussées.

Faire rentrer de l’Agilité dans un WBS (Work Breakdown structure), c’est quelque chose qui arrive fréquemment en entreprise, car cela apparaît souvent comme la meilleure solution quand on n’a connu que le cycle V.

Pourtant, on pourrait faire autrement !

Par exemple, dans le cadre d’une application qui serait décommissionnée à une date butoir, tout retard prendrait des proportions démesurées et se terminerait généralement de la même manière : une chasse aux sorcières au sein des équipes.

L’Agilité est utilisée comme un accélérateur censé permettre aux équipes de tenir leurs délais en étant plus véloces.

Comme tu le sais, l’équipe doit rendre des comptes au chef de projet, qui rend lui-même des comptes au manager, qui rend des comptes au comité de pilotage.

Et les sponsors sont les principaux décisionnaires.

Lorsque la question du “Quand pensez-vous que X sera terminé ?” est posée, plusieurs forces rentrent en collision.

Il y a tout d’abord la confiance qu’ont les managers envers la capacité à faire de leurs équipes qui est tout de suite mise à rude épreuve.

Il y a, ensuite, ce qu’on définit comme prédictible et non-prédictible, une tentative [vaine ?] de naviguer dans l’incertitude avec un minimum de contrôle.

Et il y a enfin l’arbitrage sur ce qui peut ou ne pourra pas être fait en étant écrasé par le biais des coûts irrécupérables.

Car qui dit prévisions, dit roadmap et… engagement tacite pour ceux au sommet, friands de calendriers et de deadlines.

Tu vois où je veux en venir ?

La plupart des gens vont vouloir bien faire en raisonnant ainsi :

Comment combiner rigidité calendaire, prévisibilité dans la capacité à faire tout en étant précis dans ce qu’on met dans les chiffrages ?

Mais ce nœud à la tête est un mauvais point de départ et une équation insoluble car inadapté au contexte.

Raisonner en story points, en jour/homme ou en taille de T-shirts n’est clairement pas la bonne solution pour solutionner le casse-tête de la prévisibilité et des prévisions.

Pris dans ce sens, ça fonctionne rarement.

Voyons donc les autres pistes à explorer en commençant par ne pas confondre les deux termes.

La prévisibilité, c’est la capacité d’une équipe à produire un résultat stable et reproductible, indépendamment de la date à laquelle on lui pose la question. C’est une propriété du système, mesurée dans le temps, qui s’appuie sur du vécu : du débit, un cycle time, une variabilité qu’on apprend à connaître sprint après sprint.

La prévision, c’est tout autre chose : c’est l’exercice [souvent périlleux] de projeter un résultat futur à partir de données partielles. Une prévision n’est jamais une vérité, c’est une probabilité habillée avec des “ Si”, des “Certainement” ou des “Possiblement”. C’est ce qui est souvent privilégié en PI Planning.

Le problème, c’est que dans 9 cas sur 10, on demande une prévision à des équipes… qui n’ont jamais eu droit à la prévisibilité.

On demande un chiffre, une date, un engagement alors qu’on ne leur a jamais laissé le temps de stabiliser leur rythme. C’est un peu comme demander la même durée de trajet à un chauffeur de bus, qu’il pleuve, qu’il vente ou que la circulation soit dense ou non.

La vélocité n’est pas une unité de prévisibilité, c’est un artefact de planification interne à l’équipe

On ne le répétera jamais assez : la vélocité n’a de sens que relativement à elle-même, sprint après sprint, jamais en valeur absolue, et encore moins une fois convertie en jours/homme pour nourrir un Gantt qui attend sagement sa date de fin.

Personnellement, si je suis amené à l’utiliser, c’est uniquement pour le PI Planning et rien d’autre.

Et, comme toujours, dans un seul but : rassurer le management.

D’ailleurs, je me suis toujours amusé à observer comment elle était utilisée afin d’évaluer la sécurité psychologique au sein des équipes.

C’est un excellent indice !

Ce que les organisations devraient plutôt chercher, c’est améliorer la collecte de leurs données afin de prendre de meilleures décisions.

Si je suis autant attaché à la donnée en tant que Scrum Master, c’est parce que j’ai passé trop de temps à devoir justifier ce qui m’apparaissait évident.

On ne peut améliorer que ce qu’on mesure. En 2026, les estimations “au doigt mouillé”, cela devrait être du passé. Et pourtant….

La première chose que je recommande est d'arrêter de demander systématiquement : « Quand sera-t-il terminé ? » et de remplacer cette question par : « Que savons-nous aujourd'hui qui nous permet d'avoir confiance dans cette échéance ? ».

La différence est loin d'être anodine. La première pousse les équipes à produire une réponse, même lorsqu'elles ne disposent d'aucun élément fiable. La seconde les invite à partager des faits, des mesures et des risques.

Ensuite, vient l’alternative connue : les approches probabilistes.

L’argument se tient : plutôt que de s’orienter vers des dates fixes, on présente plusieurs scénarios avec un niveau de confiance associé, les fameux percentiles : 50, 70 ou 85 % de probabilités de livrer X à telle ou telle date.

Grâce à cela, on inclut l’incertitude, le risque et on se donne le choix d’y aller ou pas.

Sauf qu’une simulation de Monte-Carlo ou un intervalle probabiliste repose sur une hypothèse implicite : le futur ressemble raisonnablement au passé. Autrement dit, les données historiques sont représentatives de ce qui va arriver.

Une haute variabilité de delivery fait voler en éclats cette hypothèse.

Une équipe qui travaille simultanément sur plusieurs projets, qui reçoit des demandes imprévues, des incidents de production, des urgences métiers et dont les priorités changent chaque semaine ne possède pas un système stable. Elle possède un système hautement variable.

Le problème n’est donc pas la probabilité.

Le problème est que la distribution sur laquelle elle s’appuie n’est plus stationnaire.

Dans ce cas, qui est finalement assez courant, il ne s’agit plus de faire des prévisions, il s’agit de qualifier le système.

Si ce système n’est pas suffisamment stable, alors une prévision n’a aucun sens. On ne réduit pas l'incertitude en améliorant les estimations. On la réduit en diminuant les causes de variabilité qui perturbent le système. Rares sont les Scrum Masters qui vont l’objectiver clairement.

On peut, en premier lieu, examiner la dispersion du cycle time, le WIP, le taux d’interruption, le pourcentage de travail non planifié, la stabilité du débit etc.

Mais si ces indicateurs sont trop erratiques, je ne chercherais pas à produire une meilleure prévision.

Je chercherais d’abord à réduire cette variabilité.

Si on se retrouve avec des équipes plateforme ou des équipes de maintenance, l'alternative consiste alors à changer complètement de modèle de prévision.

Au lieu de prévoir une date de fin pour un périmètre donné, on regarde ce qui rentre dans le système.

En Kanban, on oublie souvent de regarder le débit d'entrée alors qu’il est tout aussi important que le débit de sortie.

Pendant un mois, on peut mesurer combien de demandes arrivent chaque semaine, de quel type elles sont, lesquelles interrompent le travail en cours et lesquelles sont réellement prioritaires.

Mais compter les items entrants ne suffit pas. Il faut pouvoir les lier à des temps de cycle afin d’établir des corrélations. Un bug peut prendre plus de temps à être résolu qu’une demande métier.

A défaut, une approximation grossière est largement suffisante car l'objectif n'est pas d'être exact. L’objectif est de ne pas être complètement à côté de la plaque.

Peu vaut mieux que rien du tout.

Souvent, le problème n’est pas la CAF de l’équipe. Celle-ci arrive, la plupart du temps, à délivrer, même dans la douleur.

Le problème est que le système au complet accepte plus de travail qu'il n'est capable d'en absorber.

On peut pointer du doigt le manque de priorisation du backlog par le Product Owner, mais cela n’explique pas tout. Ce dernier peut, lui-même, être aspiré par le système, à courir à droite à gauche entre plusieurs équipes pour tenter d’exister.

Un individu est rarement la seule cause de la défaillance d’un système, il en est souvent l’une des résultantes collectivement admises. N’oublions pas la fameuse citation tirée du Manifeste Agile :

“ Les individus et leurs interactions, de préférence aux processus et aux outils” qui sous-entend que les individus influencent le système et ne sont jamais en dehors.

Et dans cette situation, les pourcentages de capacité deviennent une conséquence et non plus une décision arbitraire.

Le but n’est pas de calculer une prévisibilité factice, mais plutôt de concevoir un système de mesure minimal

Autrement dit, avant de piloter la capacité, il faut rendre le travail observable. Tant que les flux d'arrivée, les interruptions et les temps d'attente ne sont pas visibles, parler de pourcentages de capacité est une illusion assumée. C’est seulement après quelques semaines d’observation que ces pourcentages cessent d’être une intuition et deviennent un véritable outil de pilotage, encore faut-il avoir le temps de les analyser.

La variabilité ne disparaîtra jamais complètement. Le développement de produit reste une activité de découverte, avec des inconnues techniques, des évolutions de besoin et des arbitrages permanents.

Il en va de même pour l’incertitude.

Vouloir les faire disparaître à tout prix, c’est se tromper de combat et cela ne rendra pas service à l’équipe. Les accepter, c’est apprendre à naviguer entre les compromis et surtout, construire un système résilient, au-delà d’être plus stable.

Avoir un système stable ne dit pas qu’il est résilient. Et sans plonger dans les DORA metrics ici [ce n’est pas le sujet de cet article], il est fondamental de ne pas confondre également stabilité et résilience. C’est ce qui découle directement de la confusion entre prévisibilité et prévision.

Un enchaînement de fausses certitudes qui crée malentendus, tensions et pressions en tout genre au sein de beaucoup de DSI.

Dur à avouer, mais c’est bien dans les moments les plus compliqués qu’on éprouve réellement la résilience d’un système, pas quand tous les voyants sont au vert.

Et toi, quel est ton avis sur le besoin de prévisibilité et de prévision au sein des équipes ? Selon toi, est-ce qu’il répond à une crainte implicite ou aide-il vraiment à prendre les bonnes décisions ?

J’ai hâte de te lire 😁​
C’était Bruno pour te servir,

Tchô !

“Attends, on a besoin d’un budget quand on est agile ? Je pensais que la transformation agile ne se terminait jamais ”

S'abonner maintenant

Alors, oui, une transformation agile dans une organisation pouvait, jusqu’à nos jours, durer très longtemps.

Mais, au final, elle avait bien une date de fin et c’était le moment où l’enveloppe dédiée était épuisée.

[Toutes les équipes font des Sprints ? Super, on est maintenant agile. On va pouvoir couper le robinet !] — Un manager très confiant en 2016.

Mais, concrètement, combien ça coûtait FINANCIÈREMENT d’être agile ? Qui payait quoi ? Est-ce que ça coûtait VRAIMENT moins cher que si on ne l’était pas ?

Et la question qui tue, aujourd’hui : Est-ce que ça valait le COUP ? 😏

Il sera difficile de répondre à ces questions, tant les exemples et contre-exemples s’opposent et ne pourront être représentatifs de l’exhaustivité des transformations agiles qui ont eu lieu durant les dix dernières années, mais je vais tout de même essayer d’apporter mon (humble) point de vue en deux actes.

Mon parti pris sera de me concentrer UNIQUEMENT sur les coûts financiers de la transformation agile (le coût psychologique humain ne sera pas pris en compte ici).

Afin de développer mon propos, je vais partir de contraintes réelles que l’on peut observer (pas toujours, mais souvent) afin de fournir une réponse qui ne soit ni trop biaisée, ni trop limitée.

1. Le point de départ : l’audit

“ On doit être agile ”

Quatre mots lâchés en plein COMEX qui sonnaient le point de départ officiel de la transformation agile sur un nouveau territoire.

Souvent, cela sonnait comme un appel à l’aide face à une situation critique.

On voulait savoir où on en était et, dès le début, la question du portage budgétaire se posait.

La transformation Agile était rarement une initiative bottom-up bien préparée. C'était une décision du COMEX imposée de manière unilatérale. On décidait d'abord, on chiffrait ensuite et on arbitrait jamais. La gouvernance financière courait après la stratégie.

Le vaisseau amiral, c’était la DSI (Direction des Systèmes d’Information), qui allait soit faire appel à un prestataire externe pour son audit (par exemple, IBM), soit le mener en interne en mobilisant quelques personnes (solution moins chère, mais pas gratuite).

Comme souvent, les équipes n’étaient pas consultées dans la prise de décision et elles subissaient la transformation autant qu’elles en bénéficiaient. Personne n’irait leur demander de financer quelque chose qu’elles n’avaient pas souhaité et dont elles ne mesuraient pas la valeur.

En gros, porter la responsabilité financière de la transformation obligait :

• à arbitrer entre des directeurs qui défendaient leur périmètre

• à inscrire dans les budgets des postes qu'on ne savait pas encore justifier

Donc personne n’était prêt à assumer.

Cet imbroglio faisait qu’on itérait, de réunions en réunions, vers une solution plus ou moins acceptable pour la majorité. Ce qu’on mesurait rarement, c’était l’audit : ce dernier pouvait coûter cher, mais il passait systématiquement sous les radars de la transformation.

J’ai notamment observé cela dans une grande entreprise du CAC 40 (je ne citerai pas de nom, ici).

Coût : entre 40 000 et 80 000 € de masse salariale consommée pour une équipe de 3 personnes mobilisée pendant 2 mois à mi-temps.

2: Le Coach externe parachuté sur la map comme dans Fortnite

Pas de contexte, pas d’historique, mais dix ans d’expérience.

Un mois sur le terrain, parfois deux, rarement plus…

Bien trop court pour dresser un diagnostic pertinent et la tentation de se précipiter vers une solution toute faite.

Scrum, SAFe, LeSS, Flight Levels… Le choix du framework était présenté en COMEX comme une question de culture et de méthode. En réalité, c'était le moment où l'on signait un chèque sans en avoir l'air.

Aucun framework n’étant gratuit, la DSI financait les rôles et les certifications techniques. La DRH co-financait parfois les formations transverses. Les équipes étaient spectatrices, toujours.

Le Coach formait rapidement les équipes et s’en allait une fois le contrat rempli.

Bis repetita.

Compter entre 20 000 et 60 000 € pour son intervention selon sa complexité et sa durée.

3. L’industrialisation par les frameworks sur étagère : l’effet “McKinsey de l’Agilité”

Une fois le coach parti avec son chèque, le COMEX se retrouvait face à un gouffre : comment passer à l’échelle 500 ou 2000 personnes ? C’est là qu’intervenait le plus populaire des frameworks des années 2010 : SAFe (Scaled Agile Framework).

Pourquoi SAFe ? Comme je l’ai déjà dit, la transformation Agile était rarement une initiative bottom-up bien préparée : c’était une décision du COMEX votée de manière unilatérale.

Et il se trouvait que le framework SAFe avait été conçu spécifiquement pour adresser cette problématique systémique.

Lorsque j’évoque la polysémie de l’Agilité, je n’oublie jamais de souligner que SAFe s’était lui-même inscrit comme un cheval de Troie agile à l’époque (voir l’article ici)

Tout le monde en parlait et il était (presque) normal que la plupart des grosses boites aient voulu essayer, histoire de ne pas rater le train (SAFe) 😅

Ce même syndrome FOMO se répète aujourd’hui avec l’IA.

Je ne vais pas faire de laïus sur ce framework car tout a déjà été dit ou presque à ce propos, alors reprenons…

Un PI est coûteux, mais ne pas le faire l’est encore plus. Ce focus sur l’alignement des équipes autour d’un objectif commun est à mettre au crédit de SAFe, même si cela aurait pu être évité si l’architecture du système permettait plus de collaboration entre équipes (voir l’article ici)

Coût du PI : environ 150 000 € de masse salariale immobilisée par PI Planning, répété 4 à 5 fois par an.

4. Les certifications, des cases à cocher

Les certifications, un business qui a permis l’essor des organismes de formation, ont été une autre conséquence de l’Agilité marketing.

SAFe Practitioner, SAFe RTE, PSM I, PSM II, PSPO, CSM… Toutes ces certifications rattachées aux frameworks n’avaient qu’un seul but : combler un besoin de réassurance auprès des organisations clientes.

• Côté service achats, on cochait une case “Agile” dans un référentiel de compétences.

• Côté managers, on intégrait le changement dans le planning avec une date de fin

• Côté équipes, on se formait en 2 jours et on cochait chaque cérémonie mise en place

Mais, surtout, on distribuait des rôles à des personnes qui (souvent) n’avaient rien demandé (RTE, Product Owner, Scrum Master…)

En 2019, la naissance de la certification Qualiopi sous l’impulsion de la loi 2018 pour la liberté de choisir son avenir professionnel, accéléra la croissance du marché très concurrentiel de la formation.

Avec ce nouvel eldorado, beaucoup de praticiens se reconvertirent en formateurs professionnels, s’éloignant petit à petit de la réalité des organisations.

La contrainte de la normalisation fossilisa les pratiques sous un cadre plus théorique que pratique.

Cette nouvelle dépendance entre clients, organismes et cadre Qualiopi, avait créé un système dans lequel les praticiens se retrouvaient pied et mains liés, obligés de vendre des formations de conformité.

Compter entre 800 et 2 500 € par personne selon la certification et l'organisme, hors temps de travail mobilisé. Multiplié par 50, 100, 200 personnes dans une grande organisation, on approchait rapidement les 500 000 € sur deux ou trois ans.

5. L’amalgame framework = Agile et ses conséquences

Au fil des années, pour les organisations, l’Agilité était devenue un package vendu par les ESN :

• Un framework + des formations + des armées de consultants coachs/scrum masters afin de veiller à ce que tout se passe bien avec des métriques de conformité plutôt que des métriques d’impact

• On voulait accélérer (et c’est toujours le cas, aujourd’hui) sans prendre en compte la dette organisationnelle

• L’amalgame framework = agile devenait grossièrement la même chose

Ce système avait prospéré durant les dernières années et, pendant un temps, cela avait pu fonctionner car de nombreuses personnes demeuraient convaincues du bien-fondé de la démarche.

“ C’est ce que nous devons faire pour survivre dans ce monde ultra compétitif “

Mais cet amalgame entre la mise en place du framework et la réalité du terrain a créé deux problèmes :

• D’une part, l’émergence d’une certaine idée [erronée ?] de ce qu’était l’Agilité sur le terrain, alimentée par la communauté agile elle-même

• D’autre part, un enfermement des praticiens dans les cadres dans lesquels ils évoluaient et qui imposait une injonction tacite : ne faire UNIQUEMENT que ce qui était prescrit, sous peine d’échec inévitable.

Ces deux problèmes ont entériné l’idée que pour “faire de l’Agile”, il fallait suivre les règles des frameworks à la lettre, appliquant le concept de SHU HA RI avec un zèle extrême.

Comment pourrait-on prétendre que cela ne fonctionne pas si on ne l’applique pas de manière rigoureuse ?

Un questionnement rationnel qui, néanmoins, réduisait l’Agilité au statut de méthode applicable partout, ce qui était inexact.

Beaucoup d’organisations n’avaient pas acheté l’Agilité. Elles avait acheté un sentiment de contrôle.

Car, derrière chaque framework, se cachait une promesse implicite :

« Cette fois, on va réussir à coordonner tout le monde. »

« Cette fois, on va livrer plus vite. »

« Cette fois, on va arrêter les guerres de territoire. »

Mais on ne faisait que rajouter une couche supplémentaire

En résumé, chacun des rouages a participé à un système fermé, auto-référentiel, qui se nourrissait de lui-même et dans lequel la question : "Est-ce que ça marche vraiment ?" devenait presque inconvenante à poser.

Mais la collision avec la réalité était inévitable.

Compter entre 15 000 et 40 000 € de coût de remplacement par profil, selon la taille de l'organisation et le niveau de séniorité. Sans compter la mémoire organisationnelle perdue avec les départs successifs.

6. L’heure du bilan, fin 2022

L’après Covid révéla les limites des transformations Agiles (à distance, le PI, c’est pas la même chose 🫣).

Ce fut le début d’une rupture profonde entre les organisations et les praticiens.

• L’économie française n’ayant pas repris son niveau d’avant Covid, il n’était plus question d’investir massivement dans l’Agilité comme les années précédentes

Le message était clair : le “médicament” avait été prescrit, mais pour certaines entreprises, la pilule ne passait TOUJOURS pas.

Le service achats se sépara des Coachs Agiles, Scrum Masters, Product Owners, mais pas n’importe lesquels : ceux qui avaient dilué leur valeur dans des gesticulations de façade, le fameux “théâtre” agile.

L’argument massue ? Après trois belles années, les transformations Agiles s’achevaient et l’enveloppe dédiée était épuisée.

Une question que personne ne posait vraiment était devenue incontournable :

« Si l’on supprimait demain toute la structure de transformation agile, qu’est-ce qui disparaîtrait réellement ? »

Cette question a fait très mal car elle s’attaquait à la valeur plutôt qu’aux intentions.

Mais, à l’époque, pouvait-on réellement stigmatiser les “mauvais” élèves ? Toutes ces personnes qui, après avoir lu le Scrum Guide, étaient jetées dans l’arène des grandes entreprises sans filet de sécurité ?

Au fond, elles n’exécutaient que ce qu’on leur avait demandé, rien de plus.

• Passer des certifications, animer des événements, mesurer la vélocité, créer des rapports de suivi agiles…

Personne, à l’époque, ne trouvait cela si mauvais.

Les ESN imposaient la plus grande docilité afin de ne pas “froisser” un gros client. Les organisations absorbaient les PI sans réelle remise en question.

Quid de la valeur apportée et de son impact ? Aux oubliettes !

Si l’on faisait les comptes de cette décennie de ferveur agile (2015-2022), le bilan comptable serait pour le moins mitigé.

Le biais du survivant, l’effet IKEA, le rebranding, l’effet de responsabilité héritée… Il y y eu autant de positif que de négatif durant cette période.

Et autant de fans que de haters, il faut le reconnaître.

Cette question du bilan de l’Agilité divisa et divise toujours : certains voyaient le verre à moitié plein, d’autres le voyaient à moitié vide et les études sur le sujet n’étaient pas éprouvées scientifiquement afin d’éclairer les débats avec des données fiables.

Dommage…

Alors, est-ce tout cela en valait le coup ?

L’Agilité n’était pas une mauvaise idée. C’était même une excellente idée de départ, mais on a sous-estimé son coût : plusieurs millions d’euros d’investissement pour, parfois, des résultats dérisoires.

L’Agilité n'était pas trop chère pour ce qu'elle promettait. Elle a été hors de prix pour ce qu'on en a fait. Et je pense que personne, pas même les praticiens, n’avait mesuré les conséquences d’implémenter une solution en minorant TOUS ses coûts.

Financièrement, elle a généré de la valeur dans les entreprises qui ont accepté de se regarder en face. Elle a permis d’identifier certains silos, tout en échouant à les faire disparaître complètement. Et cette incapacité à tenir ses promesses a alimenté les critiques à son encontre.

L'Agilité sur étagère a échoué. Elle a créé une nouvelle bureaucratie, une couche de middle-management "agilisée" qui a remplacé les anciens indicateurs par de nouveaux rapports de conformité. On a dépensé des fortunes pour acheter un sentiment de contrôle plutôt qu'une réelle capacité d'adaptation.

Le point positif (car il y en a un) : Le logiciel a changé de modèle de livraison. On ne livre plus des projets en mode "Big Bang" après 18 mois d'effet tunnel sans voir un utilisateur. L'idée même de tester, d'échouer rapidement et de découper la valeur s'est ancrée dans les mœurs techniques.

Et quand on rassemble les pièces du puzzle, on se rend compte que le coût de l’Agilité, qui n’a ni été interrogé, ni été mesuré en tant que tel depuis le début, a alimenté une dette que, nous, agilistes et organisations, payons au prix cher.

Le fameux retour sur investissement agile : suppression des postes, baisse des TJM, missions courtes, toussa, toussa…

2022 marqua la fin d’un cycle : celui de l’hégémonie des frameworks sur le mouvement Agile et le début d’un autre : la place de l’Agilité à l’ère de l’IA.

De nombreux praticiens ont commencé à créer leurs propres méthodes et à les publier sous forme d’articles, de livres ou même de nouveaux frameworks.

Je salue ces initiatives individuelles et les respecte, tout en m’interrogant sur ce que cela dit de la période que nous vivons aujourd’hui.

Traversée du désert ? Perte de sens ? Flottement ? Tentative de survie sur le marché ?

Sommes-nous, en tant que praticiens, toujours en décalage avec la réalité des entreprises qui nous embauchent ?

Ce sera l’objet de la seconde partie de ce texte : L’IA, sauveur ou fossoyeur de l’Agilité ?

C’était Bruno pour te servir,

Tchô ! 🤗​

Abonnez-vous maintenant

En ce mois de mai, trois nouvelles ressources sont disponibles dans la bibliothèque de l’Agile Radiator.

Flight Levels - Klaus Leopold & Siegfried Kaltenecker

Le livre Flight Levels Introduction de Klaus Leopold et Siegfried Kaltenecker présente un modèle de pilotage organisationnel qui relie stratégie, coordination et exécution à travers trois niveaux appelés Flight Levels.

Les auteurs expliquent que les problèmes de performance ne viennent pas uniquement des équipes opérationnelles, mais souvent d’un manque de coordination transverse (Flight Level 2) ou d’alignement stratégique (Flight Level 3), et proposent des systèmes visuels et collaboratifs pour fluidifier le flux de valeur.

A retrouver dans la section “Agilité”

The State of Product Management Report 2025

Le document The State of Product Management Report 2025 montre que les équipes produit se recentrent fortement sur la stratégie produit, la mesure des outcomes business et l’alignement avec les besoins clients dans un contexte d’incertitude économique et d’adoption massive de l’IA.
Le rapport souligne également une tendance forte à la consolidation des outils afin de réduire les silos, améliorer la visibilité et standardiser les pratiques entre équipes produit, engineering et business.
Enfin, l’étude met en évidence que l’IA est désormais largement intégrée dans les organisations, mais que les entreprises les plus performantes sont celles qui utilisent l’IA pour améliorer la qualité des décisions et non simplement accélérer l’exécution.

A retrouver dans la section “Product Management”

Understanding Complexity via Network Theory - Vaiva Vasiliauskaite

Le document Understanding Complexity via Network Theory: A Gentle Introduction montre que les systèmes complexes peuvent être mieux compris en analysant les relations entre leurs composants à travers la théorie des réseaux.
Il explique de manière accessible comment des structures comme les hubs, les communautés ou les interconnexions influencent les comportements émergents dans des systèmes sociaux, biologiques ou technologiques.

A retrouver dans la section “Science du complexe”

NEWSLETTER

La posture d’Agence afin de by-passer le service achat

Pourquoi envoyer des CV comme un bot ne fonctionne plus en 2026

A lire ici

NEWSLETTER

LinkedIn burn-out ?

Pourquoi la chute d’engagement de LinkedIn est un signal

A lire ici

NEWSLETTER

5 hacks pour que ton CV te ramène des opportunités chaque semaine

Le mystère des ATS dévoilé 👀

A lire ici

Nouveau code d’accès à la librairie (valable un mois) :

Et n’hésite pas à proposer tes ressources gratuites dans la section “Envoyer sa ressource”.

Accès à l’Agile Radiator =>> ICI !

C’était Bruno pour te servir,

Tchô ! ☺️

Abonnez-vous maintenant

Hello tout le monde !

Aujourd’hui, il faut qu’on se parle du CV.

Non, parce que je te vois venir…. Je remarque déjà que tu lèves les yeux au ciel en soupirant rien qu’en pensant à la rédaction de ton CV.

Généralement, le CV, c’est le truc que l’on fait par nécessité, pas par plaisir.

C’est sous-côté de fou et ça gonfle tout le monde.

On le rédige nonchalamment et puis on l’intègre sur nos job boards en espérant que ça morde.

SAUF QU’IL NE SE PASSE RIEN !

Voilà ce que font 90% des gens (peut-être toi aussi, qui sait ?) :

• Ils vont chercher un template gratuit sur Freepik au format Word ou PPT (généralement un beau design avec photo et plusieurs colonnes : Expériences, Compétences, Hobbies…)

• Ensuite, ils y intègrent leur propre photo ainsi que leurs expériences

✅ Visuellement, ça claque

❌ Commercialement, c’est un désastre

Parce que, en vrai, les recruteurs, les clients et les bots, ils se moquent complètement que le CV soit BEAU.

Et le pire, c’est qu’ils en voient tellement défiler sous leurs yeux qu’ils détectent instantanément les copies.

Pour être honnête, j’ai gardé de mauvaises habitudes de mon ancienne carrière de webdesigner, notamment celle de vouloir ABSOLUMENT faire de mon CV une oeuvre d’art.

Ouais, rien que ça !

C’était vraiment utile quand j’étais webdesigner. Cela permettait au recruteur de se projeter dans mon univers graphique.

Mais cela n’avait plus aucun sens à partir du moment où je suis devenu Scrum Master / Agile Team Coach.

Et la réalité m’a frappé en plein visage : je ne m’étais jamais donné la peine de comprendre le fonctionnement des ATS.

C’est bête, mais peu de personnes s’intéressent à ça, alors que c’est littéralement ce qui transforme ton CV en aimant à opportunités.

Mais d’abord, qu’est-ce qu’un ATS ?

Un ATS (Applicant Tracking System) est un logiciel de gestion des candidatures utilisé par les entreprises pour automatiser et centraliser l’ensemble de leur processus de recrutement.

En pratique, c’est le système qui reçoit ton CV lorsque tu postules en ligne, l’analyse, l’évalue et décide si un recruteur humain le verra ou non. En gros, dès que tu remplis un formulaire et que tu y attaches ton CV, c’est 100% un ATS derrière.

Ce que la plupart des gens imaginent, c’est que dès qu’ils envoient leur CV via un formulaire, le recruteur va directement le recevoir dans sa messagerie.

❌ FAUX !

La vérité, c’est que le recruteur est en bout de chaîne.

Il passe après l’ATS.

C’est l’ATS qui doit être convaincu de présenter ton CV… ou l’ignorer.

En 2025, Jobscan a analysé les pages carrière des 500 entreprises américaines du Fortune 500 et détecté un ATS chez 97,8% d'entre elles.

La segmentation par taille est nette : 70% des grandes entreprises américaines utilisent un ATS, contre seulement 35% des PME de moins de 500 salariés.

Fais le parallèle avec la France et tu comprendras rapidement que l’ATS, c’est un marché qui pèse des milliards.

Mais voilà ce dont PERSONNE ne parle.

88% des employeurs américains estiment perdre des candidats hautement qualifiés parce que leur propre ATS les filtre, faute de CV optimisé.

Pas de réponse ? Probablement que l’ATS a mis ton CV à la 🗑️.

D’où l’intérêt de hacker le parsing.

C’est quoi, le parsing ?

Le parsing utilise des algorithmes d'extraction pour analyser les CV dans différents formats (PDF, Word, TXT), avec un taux de précision qui varie selon la qualité du CV et la technologie utilisée. En gros, l’ATS utilise l'intelligence artificielle (IA) et le traitement du langage naturel (NLP) afin de nouer des relations entre les mots.

Je passe rapidement l’OCR ou l’extraction d’entités nommées qui consistent à scanner ton CV et à en extraire les données brutes.

Abordons directement mes stratégies redoutables afin d’atteindre un score maximum.

1. Le format

Le Word > Le PDF

N’oublie pas que l’ATS doit extraire tes données.

Facilite-lui la tâche. Mets de côté tes préférences personnelles et privilégie le format Word.

2. La structure

Crée un CV clair : des sections facilement identifiables.

Pas de colonnes multiples, pas d’images et on évite les tableaux (peu lisibles pour un ATS).

Et puis, on n’écrit pas le CV pour le collègue Tech Lead 15 ans d’IT avec du pathos technique. On écrit pour des RH, des recruteurs, des personnes non-techniques qui ne sont pas censées comprendre tout le jargon.

Donc, un seul mot d’ordre : simplicité.

3. Les mots-clés

C’est 50% du score total. Autrement dit, c’est obligatoire.

Et c’est chirurgical.

Repère les intitulés de poste, les compétences techniques, les outils (ex : JIRA, Confluence…), les frameworks (ex : SAFe, Scrum) et intègre ces mots-clés dans ton CV, idéalement dans les titres, les descriptions de poste et la section "Compétences".

Cartographie le vocabulaire dominant après analyse de plusieurs annonces. Regarde 3 à 5 annonces similaires pour le même type de rôle et des patterns émergeront. Des termes comme "communication avec les parties prenantes"ou "suivi des KPI", peuvent apparaître plusieurs fois.

Ce sont des mots-clés de grande valeur à inclure si ton parcours le justifie, mais n’abuse pas : les ATS modernes détectent les répétitions excessives et peuvent te pénaliser. Vise une densité naturelle de 2 à 3% par mot-clé principal.

4. L'optimisation sémantique

N’hésite pas à utiliser des synonymes. Un ATS NLP moderne fera le lien, mais certains systèmes plus anciens ne le feront pas. En mettant les deux, tu couvres tous les cas.

Ex : "gestion de projet" et "management de projet".

Rajoute des chiffres afin de renforcer la cohérence sémantique (-20% de Time-To-Market).

Ce n'est pas juste plus convaincant pour le recruteur humain : l'ATS IA lit ces signaux de progression professionnelle comme un indicateur de qualité.

En bonus, voici le hack ultime :

Ouvre ton PDF, sélectionne tout (Ctrl+A), copie dans un éditeur de texte brut et regarde le résultat : si le résultat est illisible ou désordonné, les ATS auront le même problème.

Convertis aussi ton CV en .txt : si la mise en page reste compréhensible, ton formatage est compatible ATS.

Résultats :

• En moyenne, je reçois 3 à 4 appels de recruteurs pour des opportunités par semaine. A côté de ma prospection sur LinkedIn, ce levier est plus que bienvenu.

Au-delà des chiffres, cette statistique n’est pas du hasard, c’est une stratégie.

Si tu penses que les job boards sont morts, il est fort probable que tu n’aies pas appliqué les astuces mentionnées plus haut.

Expérimente et fais-moi un retour honnête sur tes résultats d’ici quelques semaines.

Et n’oublie pas de t’abonner à la newsletter Agile Radiator ⬛

C’était Bruno pour te servir.

Tchô ! 🙂

Il s’agit du dernier chapitre de mon arc narratif “Bilan LinkedIn en 10 leçons”.

Et il arrive à un moment clef : le changement d’algorithme a fait baisser le nombre d’impressions des posts de manière vertigineuse.

Son nom : 360Brew.

Mais je ne suis pas là pour te parler de 360Brew, surtout s’il change encore dans six mois (tu trouveras tout ce qu’il y a à savoir dessus en tapant sur Google)

Non, ce chapitre, comme tous les autres, n’est pas une liste d’actions à faire pour exploser sur LinkedIn.

Il s’agit d’exprimer un sentiment partagé par beaucoup : une saturation qui bruisse et donne de l’élan à des plateformes émergentes comme Substack.

La fameuse détoxication numérique nécessaire.

Je vais être honnête : poster tous les jours ou toutes les semaines est douloureux.

Bon, le terme douloureux est sûrement exagéré, je l’admets.

Mais je dois bien reconnaître que ce n’est pas FORCEMENT qu’une question de manque de régularité ou de manque de temps.

[Même si j’ai pu, moi-même, me juger comme pas assez régulier, il s’agit là de pure subjectivité]

Cela peut-être décourageant pour plein de raisons : trouver des idées, passer ses soirées à travailler ses posts, répondre aux commentaires afin d’augmenter l’engagement, regarder ses statistiques, constater que rien ne bouge et recommencer toutes les semaines en espérant des jours meilleurs…

Bref, c’est le quotidien de beaucoup plus de gens qu’on ne le pense.

Cela est également devenu mon quotidien.

Est-ce que cela est sain ? Je laisserai chacun juger, mais en ce qui me concerne, avec le recul, la réponse est NON.

J’ai commencé à poster il y a un an et j’ai vu des créateurs changer et devenir clivants parce que “ça marche” avec l’algorithme.

J’en ai vu quelques-uns disparaître soudainement.

D’autres s’inscrire à des formations LinkedIn ou des PODs (même quand ils ne l’avouaient pas).

Et j’en ai vu certains s’engouffrer dans la brèche pour proposer des outils afin de poster plus vite avec l’IA.

Des dizaines de créateurs en même temps sur le même business.

Un business qui tourne autour de l’écosystème LinkedIn comme des milliers d’autres avec des armadas de SaaS et d’agents IA.

Mon constat froid : LinkedIn est un endroit où il faut se répéter avec discipline chaque année pour exister. Un endroit où il faut crier le plus fort pour être remarqué.

C’est cruel, par forcément corrélé à ta valeur intrinsèque… Mais c’est le LinkedIn Game. Une boucle infinie de brouhaha incessant.

Une seule année est suffisante pour comprendre l’ensemble des mécaniques… parce que les créateurs se répètent et parce que la plateforme n’évolue pas fondamentalement.

Quand j’ai constaté que tous les posts se ressemblaient en fonction de la date, de l’événement ou de la saison, cela m’a un peu décontenancé.

Parce que je constatais que je participais moi-même à ça… et une forme de lassitude s’est installée dans mon esprit.

La quête de sens, toujours. Le “pourquoi” on fait ça…

Et je me suis rappelé les deux règles que je m’imposais sur LinkedIn :

• Trouver un job

• Ne pas devenir esclave de LinkedIn

Malheureusement, faire l’un déteint (un peu) sur l’autre.

Et pendant que je préparais mes posts pour la semaine suivante, une question me hantait :

• Que faire pour sortir de cette foutue roue de hamster ?

Début 2025, je découvre Substack.

Et c’est une révélation.

Là où certains n’ont vu qu’un énième réseau social sans importance, j’y ai vu l’opportunité que je cherchais : sortir de LinkedIn et créer mon propre système.

Un système où LinkedIn ne serait pas le moteur, mais un élément parmi d’autres d’une machine plus grande.

Un système où je mettrai enfin la valeur au bon endroit, avec calme et profondeur et surtout, sans aucune pression de régularité.

Je pense que vous avez compris : je serai moins actif sur LinkedIn et plus actif sur Substack en 2026.

Pourquoi ?

Il n’y a rien de nouveau à découvrir sur LinkedIn si ce n’est de nouvelles connexions et d’échanger avec les gens. Ce que les créateurs font, dans la durée, c’est de l’optimisation : ils optimisent tout (leur profil, leurs posts, leurs manières de vendre…) Mais ce n’est pas une révolution en soit.

C’est de l’industrialisation.

Substack, lui, a un gros avantage : il est plus complet. C’est une newsletter, un podcast, un site internet. Tu peux y expérimenter plus de choses, mais la croissance y est plus lente.

Ceci dit, je n’abandonne pas pour autant LinkedIn : je continue les carrousels !

Parce qu’au final, j’ai saisi le vrai piège : penser que gagner en visibilité va régler le problème de prospection.

Spoiler : c’est un point de vue très discutable.

Voici mes deux constats SIMPLES :

1. Ne pas être présent sur LinkedIn est un manque à gagner certain

2. Focaliser toute sa stratégie sur ce réseau social est insuffisant et risqué

C’est le vrai paradoxe. Il faut se situer au milieu.

Mais au final, ça, tout le monde le sait.

Certains vont le nier, d’autres l’oublier. Mais cette vérité est de celles qui restent.

Exemples d’autres vérités qui restent :

• Tu ne peux pas utiliser LinkedIn comme d’une source intarissable de prospects

• Tu ne peux pas t’imaginer non plus que des posts viraux vont pérenniser ton business sur le long terme

Aucune garantie. Aucune stabilité. Une grosse dépendance à un seul canal.

Ce qui est le plus pénible, ce n’est pas LinkedIn en soi, ce sont les discours pseudo moralisateurs qui t’expliquent que si tu n’as pas de nombre d’impressions astronomiques sur tes posts, c’est que tu es nul.

Que si tu n’as pas de clients via LinkedIn, c’est que tu es nul.

Que si ton offre ne se vend pas via LinkedIn, c’est qu’elle est nulle.

C’est du niveau CE1, et je reste poli. Et je ne comprends pas que ces discours portent aussi loin, comme si toute réflexion un peu plus approfondie était bannie.

Cela explique pour beaucoup cette fuite en avant vers Substack.

Mais comment faire pour sortir de la roue du hamster sans débrancher totalement de LinkedIn (parce qu’il faut bien reconnaître que c’est un levier d’opportunités incontournable) ?

Voici les règles que j’applique à moi-même :

1. Avoir une vision long terme

Si je ne suis pas autant obsédé par les likes, c’est parce que je n’utilise pas LinkedIn dans le but de rester visible pour un maximum de gens, mais plutôt pour maintenir ma présence.

La différence entre les deux ? Je n’écris UNIQUEMENT que si j’ai quelque chose d’intéressant à dire.

Cela ne signifie pas qu’il faille être invisible, mais plutôt catchy au bon moment.

Je m’autorise à republier mon contenu et à l’alimenter ponctuellement quand j’ai de nouvelles idées. Aucune pression de régularité. Inutile de poster tous les jours.

2. Prendre de la hauteur

LinkedIn est cyclique. Il y a des mois de pic et des mois moroses en activité. C’est normal. Vouloir superformer tout le temps est contre-productif.

Contrairement à ce que les statistiques tendent à nous faire croire, il ne faut pas prendre un post individuellement, mais plutôt un ensemble de posts sur une période donnée.

D’ailleurs, LinkedIn inclut les vues cumulées VS les vues de post dans les statistiques.

Plutôt malin comme fonctionnalité.

L’idée de la pertinence entre le profil, les posts et les commentaires prend également plus d’importance. Cette chute n’est donc pas dramatique.

Au contraire, il s’agit d’un réajustement plus honnête de la plateforme vis à vis des créateurs de contenu.

3. Créer des posts intemporels

Quoi de mieux que des posts que l’on peut republier afin de ne pas s’épuiser ?

Créer des carrousels ne me prend pas plus de 3h contre 10h au démarrage des publications.

Pourquoi ? J’ai créé un template afin de diviser le temps de réalisation par 4.

C’est devenu mon format signature sur LinkedIn.

4. Quels sont les résultats ?

Je programme mes publications jusqu’à 10 jours à l’avance.

Je passe tout au plus 1h par semaine à la mise en place des posts.

Je continue à être contacté par des ESN, RPO etc pour des missions à un rythme régulier (3-5 nouvelles opportunités par semaine).

Et pendant ce temps, je suis en mission, j’écris sur ma newsletter, j’approfondis mes connaissances.

D’ailleurs, j’ai tout condensé dans ce carrousel que tu peux télécharger :

Carrousel 10 Stratégies Linkedin

8.19MB ∙ PDF file

Download

Download

Conclusion :

Quand je relis mes chapitres précédents, j’esquisse un léger sourire.

Parce qu’utiliser LinkedIn en tant que créateur s’apparente à du pur empirisme et en tant que Scrum Master, je suis surpris d'identifier autant de similitudes entre ma façon de travailler et ma façon de créer du contenu sur LinkedIn.

Un éternel “Test & Learn”.

Il est possible que ces articles ne s’adressent qu’à des personnes qui n’ont JAMAIS posté ou qui ont l’intention de le faire prochainement.

Toujours est-il que le mieux, c’est de commencer à poster afin de se faire son propre point de vue sur la plateforme.

J’ai fait cette série d’articles dans le but de documenter cette expérience unique qu’est la publication sur LinkedIn afin de marquer le coup.

J’en ressors avec plus de confiance envers ma plume et moins de syndrome de l’imposteur.

C’est déjà pas mal.

Probablement que j’en rigolerai dans deux ans.

Alors, pour ceux qui sont curieux, je compte transformer cet arc narratif en e-book gratuit disponible sur l’Agile Radiator.

Bien sûr, je vais y rajouter des chapitres et le poncer un peu plus, mais j’ai hâte de le mettre à disposition de tout un chacun.

Pour ceux qui aimeraient lire ou relire les chapitres précédents, les voici :

Chapitre 1 : Se passer de LinkedIn est un secret bien gardé

Chapitre 2 : Les 2 facettes des posts LinkedIn

Chapitre 3 : La Messagerie LinkedIn

Chapitre 4 : LinkedIn est-il toujours un espace de liberté ?

Chapitre 5 : Le mythe des posts “bons” et “mauvais”

Chapitre 6 : Pourquoi est-ce si difficile de percer sur LinkedIn ?

Chapitre 7 : Pourquoi influence ne rime pas forcément avec pertinence sur LinkedIn ?

Chapitre 8 : La recherche d’authenticité est-elle une chimère sur LinkedIn ?

Chapitre 9 : Podcast “On va se dire les termes” Episode 1 : LinkedIn

C’était Bruno pour te servir,

Tchô ! 😊

“Attends, j’envoie 30 CV par semaine et j’ai aucun retour, ni entretien ”

Spoiler : ce n’est pas (forcément) parce que tu es mauvais.

C’est parce qu’il y a 100 candidats comme toi sur le même appel d’offre.

Le marché (et le marché Agile spécifiquement) est saturé… ultra saturé.

Et il est important de bien comprendre le problème de fond afin de mieux l’appréhender.

Dans cette optique, j’ai contacté séparément des confrères, Stéphane Badreau et Mickael Ruau, afin de dresser une autopsie lucide du terrain.

Je n’ai, malheureusement, pas réussi à enregistrer mon entretien avec Stéphane, mais j’ai réussi à capturer celui avec Mickael (la séquence est à visionner tout en bas).

Voici ma synthèse des 2 entretiens :

1. Si tu veux traiter en direct avec un client, ta posture ne doit plus être celle d’un simple candidat, ou même d’un freelance. Tu dois être vu comme une agence.

Réussir à by-passer le service achats* est le hack ultime, mais demande de devenir suffisamment légitime pour faire plier le système à ta volonté. C’est pour cela qu’il faut éviter de prospecter en solo, au risque de t’épuiser à spammer des CTO qui t’ignoreront de toute façon ( Le fameux : “Ça passe par une ESN référencée chez nous, désolé”).

Si tu n’es pas suffisamment connu, il vaut mieux créer un collectif afin d’augmenter tes chances.

Et des collectifs, c’est vraiment pas ce qui manque sur LinkedIn !

Cela se construit avec le temps, brique par brique. Tu dois être celui ou celle a qui le client pense avant même de lancer son appel d’offre. Pour cela, pas de recette miracle : il faut avoir une compétence rare, de celles que peu de confrères possèdent et qui répond à une douleur spécifique et pressante chez les clients.

A bannir si tu es dans l’urgence, mais effet de levier puissant sur le moyen terme.

Evidemment, il y a de (trop) rares cas, comme Rachel Dubois, Olivier My, Laurent Morisseau ou Thierry Delestre qui peuvent prétendre se démarquer avec leur personal branding, car ils ont déjà eu de solides preuves sociales auparavant (Spotify pour Rachel, livres reconnus pour Thierry et Laurent, conférences internationales pour Olivier My etc), mais ça reste le haut du panier des experts sur le marché.

(1) Service Achats : service dont l’objectif principal est de contrôler, optimiser et sécuriser toutes les dépenses IT dans l’entreprise. En gros, sans leur approbation, le budget pour t’embaucher n’est pas validé et tu n’es pas recruté.

2. L’Agilité est passée de mode. Les entreprises s’orientent désormais vers l’impact marché

D’abord, l’Agilité, dans le domaine du développement logiciel, a atteint sa phase de maturation. La plupart des grands comptes dans le secteur IT ont connu une ou deux transformations agiles. Ils attendent désormais une amélioration de leur Go-to-Market et de leur Time-To-Market au-delà des pratiques Agiles (je reviendrai sur l’importance des deux termes dans le Product Management dans un prochain article qui traitera du Product Operating Model).

Ensuite, ils ont un fort besoin en terme de structuration interne : excellence opérationnelle et delivery management : WIP, feedback régulier, expérimentations (safe-to-fail), pilotage de la livraison, alignement avec la stratégie produit etc…

Enfin, comme je l’avais déjà dit dans mon précédent article, le mot Agilité est banni au sein des entreprises. Ces débats non plus aucun sens pour elles, même si je suis convaincu que cela doit rester fondamental au sein de la communauté agile. Elles souhaitent un retour sur investissement et sont prêtes à saigner à blanc les TJM des freelances qui ne résolvent pas directement leur douleur.

3. Le marché des formations est un marché avec encore peu d’intermédiaires

C’est le marché des consultants formateurs Agiles auprès de boites plus petites ou des écoles où tu peux facturer 700, 900 ou 1000 e/jr et qui peut facilement être sans intermédiaire. C’est un modèle à pousser vers les PME/TPE sur le marché bleu avec notamment le SYCFI (Syndicat des consultants formateurs indépendants). Le TJM peut, certes, grimper, mais cela est à comparer avec le nombre d’heures passées à la préparation de la formation qui ne seront pas facturées.

4. L’allocation du budget se fait maintenant au cas par cas

Beaucoup d’entreprises allouent des budgets pour des besoins ponctuels (formations, accompagnement temporaire etc) et réalignent au fil de l’eau. Cela est beaucoup le cas dans des secteurs non-tech (par exemple, le milieu pharmaceutique pour Stéphane Badreau, soumis à de nombreuses normes réglementaires). Ce qui revient assez souvent sur le terrain, c’est qu’on utilise le PI Planning ou un simili de PI Planning, mais pas le reste du framework SAFe de manière de plus en plus assumée.

A cela, je peux rajouter la fréquente confusion entre plan capacitaire et facturation à la capacité au sein des organisations.

Le plan capacitaire est un outil de pilotage interne. La facturation à la capacité est un modèle contractuel/financier. Les deux reposent sur la même unité : la capacité de delivery. Ils sont liés, mais sont différents.

Si tu factures à la capacité, sois explicite sur ce que ça inclut : le delivery et les événements, la dette technique allouée, les congés, les dépendances. Un modèle sain de facturation à la capacité intègre un taux de delivery effectif (généralement entre 60 et 75 % du temps d'une équipe, contre 85-90 % affiché dans un modèle forfait classique). Ce delta de 15 à 25 % n'est pas du gaspillage : c'est le coût de la qualité structurelle. Mais il faut l'assumer, le nommer et le budgéter.

Le service achats a, le plus souvent, deux modèles : régie et forfait. Facturer à la capacité de delivery est un modèle conceptuellement différent sur lequel un collectif d’indépendants peut jouer afin de contractualiser en direct avec une proposition de valeur solide.

Bref, le sujet est vaste et mériterait que je m’y penche à nouveau.

Voici la vidéo de Mickael Ruau et moi.

C’est brut car ce n’était pas prévu pour le grand public à la base.

Mais je trouvais qu’il y avait trop de valeur envoyée pour garder ça que pour moi.

N’hésite pas à me faire tes retours en commentaire.

Et pour réserver un créneau de discussion libre avec moi, c’est ici.

C’était Bruno pour te servir,

Tchô ! 🙂

Et retrouve des dizaines de ressources disponibles sur l’Agilité dans la bibliothèque de l’Agile Radiator en cliquant ici

En ce mois d’avril, quatre nouvelles ressources sont disponibles dans la bibliothèque de l’Agile Radiator.

Wardley Maps - Simon Wardley

Le livre Wardley Maps de Simon Wardley explique comment cartographier visuellement une organisation ou un système pour mieux comprendre son environnement, ses dépendances et son évolution stratégique. Il propose un outil d’aide à la décision qui permet d’anticiper les changements, d’adapter sa stratégie et de gagner en avantage compétitif dans des contextes complexes.

A retrouver dans la section “Product Management”

Agile Testing - Lisa Crispin

Le livre Agile Testing de Lisa Crispin et Janet Gregory explique comment intégrer les tests au cœur des équipes agiles en favorisant la collaboration entre développeurs, testeurs et métiers. Il propose des pratiques concrètes (comme les quadrants de test) pour améliorer la qualité produit tout en soutenant une livraison rapide et continue.

A retrouver dans la section “Agilité”

Radical Focus - Christina Wodtke

Le livre Radical Focus de Christina Wodtke raconte, sous forme de fable, comment une équipe utilise les OKR (Objectives and Key Results) pour retrouver de la clarté, de l’alignement et de l’impact. Il montre concrètement comment des objectifs bien définis et mesurables permettent de focaliser les efforts, améliorer la collaboration et atteindre des résultats ambitieux.

A retrouver dans la section “Agilité”

The Cucumber for Java Book - Sebastian Ahlberg, Aslak Hellesøy et Matt Wynne

Le livre The Cucumber for Java Book de Sebastian Ahlberg, Aslak Hellesøy et Matt Wynne explique comment utiliser Cucumber en Java pour écrire des tests automatisés compréhensibles par les métiers grâce au langage Gherkin. Il montre comment appliquer le BDD (Behavior-Driven Development) pour améliorer la collaboration entre équipes techniques et non techniques tout en garantissant la qualité du logiciel.

A retrouver dans la section “Agilité”

—-

NEWSLETTER

Pourquoi des équipes confondent synchronisation et collaboration ?

Et c’est ainsi que les silos invisibles restent visibles

A lire ici

NEWSLETTER

L’Agilité : une méthode, une culture, un état d’esprit, une philosophie ou aucun des quatre ?

Et pourquoi cette confusion ne rend service à personne

A lire ici

Nouveau code d’accès à la librairie (valable un mois) :

AgileRadiator0652

Et n’hésite pas à proposer tes ressources gratuites dans la section “Envoyer sa ressource”.

Accès à l’Agile Radiator =>> ICI !

C’était Bruno pour te servir,

Tchô ! ☺️

Beaucoup de posts sur LinkedIn présentent l’Agilité comme une méthode, une culture, un état d’esprit ou une philosophie.

Il est fort possible que, toi qui me lis, tu valides ou invalides une de ces définitions.

Et il est fort possible qu’on ne soit pas d’accord… ou pas !

C’est parfaitement normal.

Je me suis moi-même surpris à parler de “culture” agile, bien plus par habitude que par réelle conviction.

"Culture eats strategy for breakfast" Peter Drucker

Cette expression, tu as dû sûrement l’entendre ou la lire.

Elle est devenue un leitmotiv dans le monde du management et a été largement reprise afin d’expliquer que les échecs des transformations agiles n’étaient pas tant un problème de stratégie, mais de culture de l’innovation et de l’expérimentation au sein des entreprises.

En soit, pas de problème à cela. Nous sommes tous et toutes issus d’horizons différents et nos visions peuvent diverger.

Le problème, ce sont les contradictions d’un praticien à l’autre.

Plus j’y réfléchis, plus je me dis que ce flou artistique au sein de la communauté ne fait que rajouter de la confusion sur ce qui se passe vraiment lors d’une transformation agile.

Si nous, praticiens, sommes incapables de définir clairement ce que nous prescrivons, comment les organisations pourraient-elles le faire ?

Entendons-nous : je donne ici mon avis (qui n’engage que moi) sur ce que je définis comme l’Agilité au sens large. Je ne m’attends pas à ce que tout le monde soit d’accord.

Ce débat sera toujours ouvert, mais en ce qui me concerne, voici ma réponse (en version longue).

Le ver était-il dans le fruit dès le début ?

Reprenons depuis le fameux Manifeste Agile de 2001, à Snowbird, Utah.

17 praticiens rédigent ce qui deviendra le Manifeste pour le développement Agile de logiciels. Le document est volontairement succinct : 4 valeurs, 12 principes et c’est tout.

Le cadre est posé, délimite un territoire bien défini et fait le choix d’une préférence sur certains éléments, tout en reconnaissant la valeur des autres.

« Cela signifie que les éléments de droite ont de la valeur, même si nous préférons les éléments de gauche. »

Selon moi, cette nuance subtile a pu être la source d’une grande incompréhension collective, au point que cette confusion est devenue elle-même une sorte de référence.

On peut également y voir l’une des raisons de la méfiance des organisations envers l’Agilité, même si elle n’est pas la seule.

Bien que le préalable logique nécessaire pour donner du sens à l’Agilité ( l’interpréter -voire- l’incarner, si besoin ) soit respecté dans le Manifeste, forcé de reconnaître que la surinterprétation ( prêter au Manifeste des ambitions qu’il n’a pas ) s’est petit à petit propagée dans toute la communauté.

La complexité ne pouvant pas être abordée de manière binaire, cette surinterprétation a pu aider à répondre à une réelle aspiration : un accomplissement souhaité qui tiendrait compte, autant que possible, de la pluralité des facteurs explicatifs à considérer.

Ainsi, la polysémie de l’Agilité a été un accélérateur massif. La plasticité du concept a pu être adaptée à de multiples contextes, étendant le champ des possibles.

En revanche, cette même polysémie a, mécaniquement, articulé des demandes hétérogènes précisément parce qu'elle est sémantiquement insuffisante.

Certain. es, bien conscients de ce paradoxe, ont avancé l’idée que l’Agilité serait tout à la fois : une culture, un état d’esprit, une méthode ou une philosophie.

D’autres ont séparé “Agile” et “Agilité” afin de distinguer la logique de reproductivité (Faire de l’Agile) et l’émergence invisible de l’état d’esprit agile (L’Agilité au sens noble du terme, “Etre Agile”).

SAUF QUE...

Quand tout est Agile, plus rien ne l’est

Pendant un temps, ce flou sur la définition de l’Agilité a agi comme un “cheval de Troie” organisationnel, se diffusant à vitesse grand V dans des entreprises variées.

Chacun pouvait y trouver son compte :

• Si l’entreprise voulait que l’Agilité soit un état d’esprit, alors ça l’était.

• Si l’entreprise voulait que l’Agilité soit une culture, pas de problème non plus.

• Si l’entreprise voulait que l’Agilité soit une méthode, pourquoi pas ?

Ce statut d’autorité était à la discrétion de l’entreprise cliente.

Mais, à contrario, cela a provoqué une immense frustration :

• Conflits d’interprétations entre les équipes, le management et les coachs.

• Fatigue organisationnelle (transformation perçue comme floue ou arbitraire…)

• Agile bashing (l’Agilité ne sert à rien)

Certaines organisations et agilistes ont adopté des pratiques sans comprendre leurs conditions d'application, puis ont intériorisé l'échec comme une défaillance de leur culture, méthode, philosophie ou état d’esprit, plutôt que comme une inadéquation de l’Agilité en elle-même dans certains contextes.

Comment définir l’Agilité ?

Depuis 2001, l’objet Agile a muté.

Penser l’Agilité en 2026 n’est pas la même chose que penser l’Agilité en 2001.

Entre ces deux dates, il y a eu des succès et des échecs qui ont eu des conséquences concrètes sur une évolution des approches.

D’un dogmatisme aveugle à du pragmatisme lucide forgé sur le terrain, il reste encore des traces bien visibles d’errements passés.

Commençons par la définition la plus (malheureusement) répandue dans les descriptifs de postes :

L’Agilité comme méthode ?

Ma réponse est, en termes stricts, non.

D’ailleurs, quand on parle des “méthodes agiles”, on mélange souvent XP, Scrum, Kanban, SAFe et tous les autres concepts identifiés comme agile-compatibles et rassemblés sous la même bannière.

Une méthode, au sens rigoureux du terme, est un ensemble de procédures systématiques, reproductibles et orientées vers un résultat défini, dans un périmètre d'application explicite, ce qui sous-entend que les contextes sont parfaitement identiques.

Or, l’Agilité ne cherche pas à “cloner” des pratiques, elle cherche à répliquer des résultats dans des contextes différents.

Elle ne réplique pas un processus défini, mais plutôt un comportement dans le système.

Le Manifeste de 2001 explique lui-même qu'il ne fournit pas de processus, mais des valeurs et des principes dont les signataires attendent que chacun dérive ses propres pratiques.

Cette définition est donc infondée.

L’Agilité comme culture ?

Idem, selon moi, l’Agilité n’est pas une culture.

Une culture est un ensemble de postulats fondamentaux partagés, appris par un groupe, qui guident inconsciemment les comportements.

Sauf que l’Agilité n’a rien d’une démarche inconsciente. Elle n’émerge pas, elle est provoquée et surtout, ELLE DEMANDE UN EFFORT CONSTANT.

C’est bien pour cela que le métier de Coach Agile existe.

Ce qui prête à confusion c’est, d’après moi, deux choses :

• Premièrement, la terminologie utilisée :

Rituels, cérémonies, artefacts… Ces termes religieux peuvent corroborer l’idée d’une certaine “culture agile” qui ne l’est pas.

• Deuxièmement, l’Agilité se superpose bien souvent à l’existant sans jamais le remplacer (et c’est ici que beaucoup d’Agilistes se méprennent)

Modifier des pratiques, des structures ou des rôles ne garantit pas que cela s’inscrive dans le temps, comme cela est le cas dans une vraie culture. Une entreprise qui favorise la hiérarchie, le contrôle ou l'évitement de l'échec absorbera bien souvent les pratiques Agiles en les soumettant à sa propre volonté. Les pratiques importées seront réinterprétées, non l'inverse.

En affirmant que l’Agilité est une culture, beaucoup d’Agilistes se trompent de diagnostic :

• La question n’est pas de savoir si une organisation est prête ou pas prête pour l’Agilité.

• La vraie question est de savoir comment l’échec est vécu et si les expérimentations sont encouragées ou freinées.

L’Agilité comme état d’esprit ?

C’est, de loin, la définition que j’entends le plus sur le terrain, en formation ou en podcast : l’Agilité serait, avant tout, un état d’esprit.

Cette définition a l’avantage de se prémunir de la réfutation : on ne peut pas “mesurer” un état d’esprit autrement que par l’adoption totale des pratiques qui en découlent.

“On a le bon état d’esprit ou on ne l’a pas”

Cette règle fait foi. C’est un pare-feu infalsifiable à une critique de l’objet Agile lui-même.

Pourtant, l’état d’esprit est un concept scientifiquement prouvé. L’Agilité, par la diversité des attributs dont elle fait appel ( naviguer dans l’incertitude, favoriser l’amélioration continue, s’adapter au changement etc) ne constitue pas une structure psychologique cohérente à part entière.

En outre, le caractère insaisissable de l’état d’esprit trace une barrière invisible entre Agilistes et organisations.

L'usage de ce terme génère une circularité logique imparable. Une équipe a “l'état d’esprit agile" si elle travaille de façon agile.

Cette circularité permet de déplacer la responsabilité de tout échec vers l'intériorité des individus.

Cet “état d’esprit agile” n’a pas de fondement psychologique éprouvé, mais il convainc efficacement via un mécanisme de culpabilisation déguisé.

L’Agilité comme philosophie ?

Elle ne l’est pas au sens fort du terme. On raccroche souvent l’Agilité à une idée, mot qui est un synonyme de la philosophie, mais il y a une nuance à apporter.

On a tous étudié les grands philosophes au lycée (Platon, Socrate…). La comparaison avec le Manifeste Agile n’est même pas proche. La philosophie répond à des problèmes fondamentaux universels (le but de l’existence, la morale…) là où le Manifeste répond à une situation universelle (agir dans l’incertitude).

Ce qui est similaire entre la philosophie et l’Agilité, c’est la mise en place de principes et de valeurs (Le Manifeste propose effectivement une nouvelle manière de penser l’action dans l’incertitude) .

Mais, malheureusement, les valeurs du Manifeste ne forment pas un système complet comme c’est le cas en philosophie.

Elles se juxtaposent sans principe d'arbitrage explicite lorsqu'elles entrent en tension.

Ce n’est pas de la philosophie, c’est un ensemble de préférences d'action située.

Ceci dit, je préfère bien plus cette définition à celle de méthode.

L’Agilité comme outil ?

C’est, selon moi, la définition la plus honnête et pragmatique.

Si l’on se concentre sur ce que l’on voit concrètement sur le terrain : des frameworks, des pratiques, des rôles, des artefacts… Tous ces éléments sont utilisés afin d’obtenir un résultat.

La définition fonctionnelle d'un outil est simple : c'est un dispositif conçu pour accomplir une fonction dans un contexte donné, avec des conditions d'utilisation, des cas d'usage optimaux et des limites. Un marteau est un outil excellent pour enfoncer des clous dans du bois. Il est médiocre pour visser des boulons. Ce n'est pas le marteau qui est en cause quand on essaie de l'utiliser comme tournevis.

Et c’est sur ce point précis que le concept d’affordance réelle et perçue proposé par JJ Gibson et repris par Don Norman prend tout son sens.

Les affordances réelles sont ce qu’un objet permet effectivement de faire, compte tenu de ses propriétés physiques et de la relation avec l’utilisateur. Les affordances perçues sont ce que l’utilisateur croit que l’objet lui permet de faire ( sa représentation des possibilités d’action offertes ). Les deux peuvent diverger massivement.

Ce n’est pas un problème de conformité avec l’usage de l’outil, mais de relation avec cet outil. Chaque organisation ne réagit pas de la même manière avec le même outil. Les organismes étant différents (histoires, structures, hypothèses…) les résultats seront différents. L’outil lui-même n’est ni universel, ni neutre.

Comme peu de gens le savent, je suis un ancien UX designer et donc très sensible à l’expérience utilisateur dans les parcours.

J’ai été heureux de constater, grâce à mes discussions avec William Bartlett, que grâce à mon ancien métier, j’ai toujours été influencé par le concept d’affordance sans le nommer lorsque j’appliquais le Design Thinking.

La notion d'affordance est probablement le cadre conceptuel le plus chirurgical pour rendre compte de ce qui se passe réellement dans les transformations agiles.

Si on applique l’affordance au Manifeste Agile, on se rend compte :

• Qu’il afforde à chaque lecteur de le trouver cohérent avec ce qu'il pense déjà. Puissant en diffusion, mauvais en application car chaque lecteur y projette un référentiel différent tout en croyant partager le même.

• Qu’il afforde la déresponsabilisation sélective par le fait que l’on peut se revendiquer du Manifeste juste par une déclaration d’intention. Il dit "Nous préférons A à B, sans nier la valeur de B". Ce “en même temps”permet l’adhésion sans obligation et, surtout, sans véritable remise en question.

• Qu’il afforde la généralisation illimitée (et c’est peut-être ici le point de bascule majeur). Il ne dit nulle part que ses principes s'appliquent seulement au développement logiciel et cette absence afforde la généralisation à tout domaine d'activité (RH, Marketing, Data, BTP etc). Résultat : une dilution progressive de son contenu.

Si les affordances émergent de la relation entre l'outil et le contexte, les interventions pertinentes portent sur les deux termes de la relation, pas seulement sur l'outil.

La première erreur est de vouloir modifier l'outil seul : essayer de changer les rôles et les responsabilités, réorganiser les événements etc. sans modifier le contexte organisationnel.

La deuxième est de vouloir faire l’inverse : essayer de changer le contexte sans introduire d'outil structurant l’intention. On modifie sans clairement savoir comment.

À cela, beaucoup d’entreprises rétorquent : comment changer sans structure ?

Et cette interrogation est légitime.

Par contre, lorsque l’on se concentre sur la relation entre l’organisme et l’outil, (l’entreprise et le framework, par exemple) on ouvre la voie à des hypothèses d’exploration :

Quelles modifications minimales du contexte permettraient d'actualiser des affordances nouvelles avec l'outil existant ?

On déplace la conversation d’une solution toute faite à un choix pragmatique où le contexte et l’outil intéragissent de concert et non l’un sur l’autre.

Conclusion :

Aujourd’hui, et pour les raisons évoquées précédemment, beaucoup d’Agilistes se refusent à parler d’Agilité sur le terrain.

Le mot est devenu un épouvantail, symptomatique de l’impossibilité de tout un chacun de le définir avec précision.

C’est dommage. Car c’est précisément ce qui explique pourquoi les praticiens ont tant de mal à légitimer leurs actions lors des transformations Agiles.

L’étude épistémologique devrait être encouragée et diffusée plus largement au sein de la communauté.

De mon point de vue, il faut garder un esprit critique sur le Manifeste Agile : comprendre qu’il donne un langage, une autorité textuelle, une appartenance communautaire et une position critique vis-à-vis des pratiques dominantes.

Mais, surtout, comprendre qu’il afforde d'être cité, pas d'être appliqué, car il est structurellement sous-déterminé pour cette fonction.

C’est sa plus grande force et sa plus grande faiblesse.

L’ affordance révèle humblement que l’Agilité n'a pas d'effets : elle a des possibilités d'effets relationnels. Ces possibilités sont réelles, mais elles ne s'actualisent que dans des relations spécifiques entre l'outil et des conditions organisationnelles particulières.

Cette nuance n’est, que trop souvent, survolée alors qu’elle est fondamentale.

Et toi, quel est ton avis sur la définition de l’Agilité ?

Penses-tu qu’il faudrait poursuivre le débat ou le clore définitivement ?

Je suis très curieux d’avoir ton retour.

C’était Bruno pour te servir.

Tchô ! 😀

Article intéressant pour comprendre la notion d’affordance : https://medium.com/@jder00/la-notion-daffordance-selon-d-norman-ea3bf1ec829b

Et retrouve des dizaines de ressources disponibles sur l’Agilité dans la bibliothèque de l’Agile Radiator en cliquant ici

L’Agilité à l’échelle de l’organisation. L’Agilité plus imposante… Plus contraignante aussi. Un nom bien ronflant pour de multiples usages plus ou moins adaptés, plus ou moins efficaces.

Ici, je parle du PI Planning utilisé avec le framework SAFe. Et non, ce n’est pas un énième pavé envoyé sur SAFe. En tous cas, pas totalement !

Si vous n’avez jamais assisté à un PI Planning, je vous laisse imaginer :

Cent vingt personnes dans une grande salle. Des tableaux couverts de post-its. Des équipes qui se tournent vers d’autres équipes, qui négocient, qui s’ajustent.

Une énergie particulière, celle des enjeux partagés et des décisions prises ensemble. On sort de là avec le sentiment que quelque chose s’est passé.

Que pendant deux jours et des milliers d’euros dépensés après, l’organisation s’est ENFIN parlée les yeux dans les yeux et a brisé ses foutus silos.

SAUF que ce n’est pas le cas (en tous cas, pas à 100%)

Il y a synchronisation ET collaboration !

La synchronisation, c'est l'alignement temporel et informationnel entre entités qui restent distinctes. Les équipes s'accordent sur quand elles livreront, sur quoi elles dépendent, sur qui attend quoi de qui. Elles ajustent leurs calendriers, cartographient leurs frontières, réduisent les surprises.

C'est de la coordination au sens classique du terme : chacun reste dans son périmètre, dans son couloir, mais on évite UN PEU BEAUCOUP les collisions. On ne s’engage pas physiquement.

La collaboration, c’est de interdépendance cognitive active. Cela va au-delà de la synchronisation. On pousse les gens à co-construire quelque chose qu’ils n’auraient sans doute pas construit tout seuls. On rend les frontières entre équipes poreuses et on laisse les membres d’équipes circuler entre eux, façon Union Européenne.

Le premier bénéfice est là : la responsabilité est partagée, pas seulement coordonnée.

Deux mécanismes distincts. Deux effets distincts sur la structure organisationnelle.

Et pourtant, dans la quasi-totalité des transformations agiles à l’échelle que j’ai observées, elles sont utilisées comme des synonymes. On dit “collaboration” en pensant “synchronisation”. On se félicite de la seconde en croyant avoir atteint la première.

Et le glissement sémantique fait son travail silencieusement : il dispense d’aller chercher ce qu’on n’a pas.

Un problème structurel que le PI embarque dès sa conception et qui est rarement questionné

Le dispositif fonctionne ainsi : les Business Owners arrivent au PI Planning avec leurs Business Epics déjà formulés, leurs priorités déjà arrêtées, leur vision de la valeur à livrer déjà packagée.

Les équipes reçoivent ces objectifs, les décomposent, puis se coordonnent entre elles pour en organiser la livraison.

Les Scrum Masters débarquent avec les capacités des équipes (leur vélocité, for sure) et commencent à faciliter ce travail de puzzle grandeur nature.

Ce que cela produit est précis : les équipes n’inventent rien ensemble. Elles organisent la livraison de contraintes qu’on leur a transmises.

La synchronisation qu’on observe au PI Planning n’est donc pas une synchronisation autour d’un problème partagé. C’est une synchronisation autour d’un calendrier imposé. Et cette distinction est radicale.

Ce que personne ne remarque ? A chaque passage de flambeau, l’intention se dégrade.

J’avais déjà parlé des filtres systémiques dans un post LinkedIn.

Le fossé de perception, on peut le représenter comme ça :

Ce que l’émetteur croit envoyer
───────────────┐
│ ← 𝑭𝒊𝒍𝒕𝒓𝒆𝒔 𝒔𝒚𝒔𝒕𝒆́𝒎𝒊𝒒𝒖𝒆𝒔
───────────────┘
Ce que le récepteur croit recevoir

Et en même temps que l’information traverse les niveaux :

📈 la confiance subjective augmente chez les managers

📉 la qualité réelle de compréhension diminue chez les équipes

Les équipes se coordonnent autour d'objectifs qu'elles n'ont pas co-créés.

Il y a une différence psychologique et organisationnelle fondamentale entre des objectifs qu'on a aidé à formuler et des objectifs qu'on reçoit à livrer.

Le PI Planning donne aux équipes de l'autonomie sur COMMENT elles livrent. Rarement sur POURQUOI elles livrent tels objectifs plutôt que d'autres.

C'est une autonomie d'exécution, pas une autonomie de direction.

Il s’agit là du principal reproche fait au PI Planning et à SAFe en général :

Dans son architecture profonde, le PI Planning reproduit un schéma waterfall avec une couche de coordination agile par-dessus. La décision stratégique se prend en amont, de façon centralisée. L'exécution est distribuée. Ce n'est structurellement pas si différent du cycle produit traditionnel.

La dérive facile vers une organisation en Feature Factory

Cette mécanique du PI Planning axée sur la synchronisation et moins sur la collaboration crée les conditions favorables à une organisation en Feature Factory, la hantise de tous les Agilistes.

Une Feature Factory, c'est une organisation qui se dit souvent “Agile”, souvent bien intentionnée, dont le mode de fonctionnement réel consiste à transformer des demandes entrantes en fonctionnalités livrables, le plus vite possible, avec le moins de friction possible.

Les équipes sont évaluées sur leur capacité à produire, pas sur leur capacité à résoudre des problèmes. Sur leur output, pas sur leur outcome.

En tant que Scrum Master, il est donc de ton devoir d’empêcher cela en l’adressant le plus tôt possible et en mettant en place des ateliers qui permettent aux équipes d’apprendre en continu, de favoriser le feedback et l’appropriation collective du problème à résoudre.

Ce n’est pas un problème dans l’organisation, mais dans la conception même de SAFe lorsqu’il doit s’intégrer dans des contextes en mouvement… ou rigides.

Tout le monde doit avancer au même pas

SAFe impose que toutes les équipes d’un ART fonctionnent avec des itérations de même durée. Deux semaines. Pour tout le monde. Quoi qu’on fasse, quelle que soit la nature du travail.

L’argument en faveur de cette contrainte est réel : la synchronisation des cadences simplifie la coordination, permet les cérémonies inter-équipes et rend le rythme de livraison prévisible. C’est un argument légitime de réducteur de friction logistique.

Mais les coûts sont structurellement sous-estimés.

Forcer des équipes aux natures de travail radicalement différentes dans le même conteneur temporel crée une friction d'ajustement permanente.

Une équipe qui fait de l'exploration technique ou de la recherche produit a besoin de cycles plus longs pour produire quelque chose de signifiant. Une équipe qui gère de petites améliorations continues pourrait fonctionner bien plus vite. Forcer les deux dans la même cadence produit soit de la sous-utilisation, soit de la compression artificielle.

C’est typiquement ce qui se passe quand on associe des équipes qui produisent des Enablers et des équipes orientées Delivery.

Chaque équipe entre dans le PI avec son conteneur temporel et cherche à le remplir de façon cohérente avec les objectifs business. L'unité d'analyse n'est plus le flux de valeur, ni le problème à résoudre. C'est l'équipe et son planning.

Les dépendances inter-équipes cessent d'être des opportunités de travail conjoint. Elles deviennent des contraintes de calendrier.

La question posée n'est plus : "Est-ce qu'on pourrait travailler ensemble sur ce problème pour le résoudre mieux ?"

Cela devient : "Est-ce que l’équipe B peut livrer à temps pour que l’équipe A puisse démarrer ?"

C'est la définition exacte de la coordination. Pas de la collaboration.

Et la System Demo à la fin de chaque itération, aussi utile soit-elle pour la visibilité, consolide cette logique : chaque équipe présente CE QU'ELLE a livré.

C'est une vitrine par équipe, pas une démonstration de valeur co-créée.

On renforce la représentation que chaque équipe a d'elle-même comme unité de performance autonome. Les silos invisibles ne le sont pas.

Un problème d’isomorphisme de cadence sous-jacent dans SAFe

Quand toutes les équipes avancent au même pas, sur les mêmes features, avec les mêmes métriques de livraison, le découpage organisationnel se fossilise.

Chaque équipe devient un rouage calibré pour son segment du pipeline. Elle optimise dans son périmètre. Elle ne questionne pas le périmètre.

Et c’est précisément l’opposé de ce que Skelton et Pais décrivent dans Team Topologies comme une organisation capable de livrer durablement de la valeur.

Dans le modèle Team Topologies, la question de départ n'est pas : "Comment coordonner les équipes ?"

C'est "comment découper les équipes pour que le flux de valeur soit naturellement aligné sur leurs frontières ?"

Ce sont deux angles d'attaque fondamentalement différents. L'un part de l'organisation existante et cherche à la coordonner. L'autre part du flux de valeur et cherche à construire l'organisation autour de lui.

Ce qui est crucial ici c’est que les modes d’interaction entre ces équipes sont aussi explicitement définis que leurs types.

Il y a la Collaboration intensive, le service rendu (X-as-a-service) et la facilitation : trois modes distincts, chacun adapté à un contexte précis, chacun limité dans le temps pour la collaboration intensive, parce que maintenir une collaboration permanente entre toutes les équipes est aussi coûteux qu’inefficace.

Dans un ART SAFe avec cadences synchronisées, cette granularité disparaît. Toutes les équipes interagissent de la même façon, au même rythme, avec les mêmes rituels. La collaboration intensive et la simple coordination de dépendance sont traitées avec les mêmes outils. Le mode d’interaction n’est jamais questionné, parce que le PI Planning fournit un format universel qui semble s’appliquer à tout.

Ce que cela produit concrètement, c'est une confusion de rôles : des équipes qui devraient être des équipes plateformes et se comporter comme des fournisseurs de services internes sont traitées comme des équipes feature au même titre que les autres, avec les mêmes attentes de livraison, les mêmes itérations, les mêmes PI Objectives.

Des équipes qui devraient avoir des cycles d'exploration longs sont forcées de "livrer" quelque chose de visible toutes les deux semaines, ce qui les pousse à fragmenter leur travail en livrables artificiels plutôt que de travailler sur les vrais problèmes.

Au final, toutes les équipes se comportent comme des équipes Feature Factory et non comme des équipes Produit, là où justement SAFe est censé agir comme un catalyseur d’une culture produit commune.

Les Collaborative Planning Events modulaires comme sparadrap temporaire

C’est une discussion que j’ai entamée avec Nicolas Poitelon sous l’un de ses posts où il expliquait en quoi faire un PI Planning ne signifiait pas faire du SAFe. J’avais alors émis une solution, puisque le fond du post était de favoriser la collaboration au-delà de la conformité ABSOLUE au framework : en effet, dans sa prise de recul sur ses propres limites, SAFe a inclu les Collaborative Planning Events modulaires.

Le format modulaire rend l'événement plus praticable pour les organisations distribuées ou hybrides. Il intègre des phases de préparation asynchrones qui améliorent la qualité des discussions. Il permet à chaque équipe de se synchroniser avec les équipes en dépendance à son propre rythme, hors PI, permettant une plus grande flexibilité. Ce n'est pas rien.

Mais cela ne règle pas le problème initial de conception du PI Planning.

La modularisation ne modifie pas le fait que les objectifs arrivent des Business Owners. Elle ne remet pas en cause la synchronisation des cadences. Elle ne crée pas de porosité entre les équipes. Elle ne change pas les métriques d'évaluation. Elle n'affecte pas les dynamiques. Et surtout, elle ne touche pas aux conditions structurelles qui produisent les Feature Factories.

Les Collaborative Planning Events rendent le PI plus digeste pour tout le monde, mais elles ne le questionnent pas fondamentalement. Ce serait d’ailleurs un peu comme marquer un but contre son camp pour SAFe, donc à la rigueur, je l’entends…

Qu'est-ce qui réduirait la confusion entre synchronisation et collaboration ?

Je vais être direct : il n’y a et il n’y aura jamais de solution toute faite pour répondre à toutes les problématiques. Aucun framework, aucune approche ne prévaut.

Sur le top-down, la vraie alternative n'est pas de sortir les Business Owners du processus. C'est de modifier le moment et la nature de leur intervention : faire participer les équipes à la formulation des problèmes stratégiques avant que ceux-ci ne soient traduits en objectifs.

Non pas pour qu'elles choisissent la direction de l'entreprise, mais pour qu'elles participent à définir ce que signifie "aller dans cette direction".

Sur le risque Feature Factory, la réponse commence par reposer la question du découpage avant de reposer la question des rituels. Team Topologies propose une heuristique utile : si une feature nécessite structurellement plus d'une équipe pour être livrée end-to-end, le découpage est probablement le problème.

L'objectif des stream-aligned teams n'est pas d'éliminer toute dépendance, c'est de faire en sorte que chaque équipe puisse livrer de la valeur autonome sans bloquer ou être bloquée en permanence.

Quand les dépendances inter-équipes au PI Planning grossissent d'un trimestre à l'autre, c'est un signal fort que le découpage ne correspond pas aux flux de valeur réels. Ce n'est pas un problème de planification, c'est un problème d'architecture organisationnelle.

Sur les cadences, la solution la plus cohérente avec la théorie du flux est de desserrer la contrainte d'isomorphisme. Reinertsen appelle ça la decoupled cadence : permettre aux équipes de fonctionner à des rythmes différents : certaines en Kanban pur, d'autres en sprints de longueur variable et synchroniser uniquement aux points où la synchronisation crée réellement de la valeur : les releases, les décisions d'architecture, les revues stratégiques.

Cela demande une maturité de coordination plus élevée. Mais c'est une maturité qui traite le vrai problème au lieu de le contourner.

Introduire des métriques d’impact

Sur les métriques (et j’insiste énormément là-dessus) il faut mesurer ce qui traverse les frontières plutôt que ce qui se produit dans chaque silo.

Le Time-To-Market d'une feature qui traverse plusieurs équipes est infiniment plus informatif que la vélocité de chaque équipe prise séparément. Et si on veut éviter la dérive Feature Factory, il faut introduire des métriques d'impact : l'usage réel des features livrées, leur contribution mesurable aux objectifs business, le taux de features qui génèrent l'effet attendu. Une organisation qui ne mesure que ce qu'elle livre ne saura jamais si ce qu'elle livre change quoi que ce soit.

La porosité, la grande oubliée des PI

Très peu d’organisations prennent ce sujet à bras-le-corps, mais rendre les frontières plus poreuses entre les équipes, c’est s’attaquer profondément aux silos, pas juste pendant 48h.

Un membre de l'équipe A qui passe une itération entière dans l'équipe B sur un problème à la frontière. Des sessions de co-conception sur les zones d'interface complexes. Ces mécanismes ne se décrètent pas, ils se conçoivent, se protègent et se mesurent activement, parce que la pression naturelle du système est toujours de ramener chacun dans son périmètre. Il faut discuter de la responsabilité partagée entre deux équipes grâce à la VSM (Value Stream Mapping).

Ce que fait le PI, il le fait bien

C'est un mécanisme de synchronisation sophistiqué et légitime.

Les hypothèses de conception de SAFe : objectifs top-down, cadences isomorphes, métriques par équipe etc… sont cohérentes entre elles. Elles forment un système logique.

Mais ce système optimise la synchronisation à grande échelle, pas la collaboration réelle. Et il crée, silencieusement, les conditions structurelles exactes pour que les équipes glissent vers la Feature Factory sans même s'en rendre compte, sans les garde-fous obligatoires que sont les Scrum Masters.

Ces derniers comblent des lacunes structurelles, là où ils devraient traiter le problème systémique que SAFe essaye de résoudre.

On livre plus, mais on apprend moins, tout en se rigidifiant.

Et c’est ainsi que les silos invisibles restent visibles, malgré la promesse de départ de les “briser”.

Quand on confond synchronisation et collaboration, on se donne une raison de ne pas chercher plus loin.

Certains diront encore que l’outil n’est pas responsable de sa mauvaise utilisation, mais cette assertion ne traite pas le problème à sa source, elle le retourne à l’envoyeur.

Il est temps d’appeler les choses par leur nom.

Pas pour brûler SAFe. Pour arrêter de lui demander ce qu’il ne peut pas donner et commencer à construire sérieusement ce qu’il prétend offrir.

Références mentionnées : Skelton & Pais — Team Topologies (IT Revolution Press, 2019), Donald G. Reinertsen — Principles of Product Development Flow (Celeritas, 2009)

La bibliothèque de AGILE RADIATOR si, toi aussi, tu veux avoir de l’impact !

Si tu veux aller plus loin dans ta compréhension de l’Agilité, la bibliothèque Agile Radiator est faite pour toi.

Tu y trouveras des ressources gratuites, des auteurs de référence sur ce qui entoure le domaine Agile et sa mise en place sur le terrain afin d’en tirer les meilleurs bénéfices.

Et si tu es un CTO, Manager ou Directeur, je te propose un accompagnement expérimental afin de résoudre tes problématiques organisationnelles de manière pragmatique et concrète.

Le code d’accès à la librairie est :

AgileRadiator0343

Le portail d’Agile Radiator : CLIQUE ICI

C’était Bruno de l’Agile Radiator pour te servir,

Tchô ! 😉

En ce mois de mars, deux nouvelles ressources sont disponibles dans la bibliothèque de l’Agile Radiator.

Gestion des conflits - M.-Cl. Audétat & Ch. Voirol

Les degrés et niveaux des conflits, ainsi que leurs facteurs déclenchants… Autant de thématiques abordées dans ce livre ; une boite à outils utile sur comment gérer les crises en équipe en tant que facilitateur.

A retrouver dans la section “Agilité”

Introduction to Neuroscience - Valerie Hedges

Adressé initialement aux étudiants, ce livre ouvre une initiation progressive à la Neuroscience et comment les neurones-miroirs et la contagion des émotions
peuvent être utiles en psychologie positive dans le management. Parfait pour approfondir sa connaissance des réactions humaines en équipe.

A retrouver dans la section “Neurosciences”

Agile Radiator - Le Podcast - Ep. 2 : L’effet de responsabilité héritée

Il y a énormément de contextes “défavorables” pour un Scrum Master.

Et tu peux être victime de l’effet de responsabilité héritée plus vite que prévu !

Un sujet rarement abordé et pourtant très connu dans la communauté.

Dans l’épisode 2 de l’Agile Radiator : le Podcast, j’aborde cette thématique de manière lucide, sans enjoliver la réalité.

A retrouver dans la section “Podcast”

Nouveau code d’accès à la librairie (valable un mois) :

AgileRadiator0343

Et n’hésite pas à proposer tes ressources gratuites dans la section “Envoyer sa ressource”.

C’était Bruno pour te servir,

Tchô ! ☺️

Les Scrum Masters sont des cibles faciles.

Soit on leur reproche leur manque de profondeur dans leur rôle, soit on leur fait un procès en illégitimité parce qu’ils n’apportent aucun impact dans leurs équipes.

Et après cela, on vient nous dire qu’un Scrum Master se la coule douce et devrait être écarté de l’équipe.

Ça, c’est l’histoire simple que certain.es veulent répandre, n’hésitant pas à rajouter les Coachs Agiles en passant.

La première coupable ? La posture ! Pas assez basse ou trop haute, elle ne trouverait jamais son équilibre idoine selon le Scrum Master.

Mais au-delà de la remise en question perpétuelle selon le contexte qui peut vite tourner à la schizophrénie, j’ai envie de prendre le sujet sous un autre angle.

Sans remettre en cause une part de responsabilité de certains Scrum Masters dans l’échec de leurs missions, il faut également reconnaître que tout n’est pas à mettre à leur discrédit.

Il y a énormément de contextes “défavorables”.

Et tu peux être victime de l’effet de responsabilité héritée plus vite que prévu !

Un sujet rarement abordé et pourtant très connu dans la communauté.

Dans l’épisode 2 de l’Agile Radiator : le Podcast, j’aborde cette thématique de manière lucide, sans enjoliver la réalité.

N’hésite pas à mettre un “J’aime” ou à commenter afin de partager ton point de vue !

C’était Bruno pour te servir,

Tchô !

“What is your level in English ? I mean it.” 💂

Il se pourrait bien que cette compétence te permette non seulement de travailler en full remote, mais augmente considérablement tes opportunités de travail.

France < Europe 🎉

Il n’y a pas match.

Habituellement, les gens travaillent dans leur ville ou leur région. Mais qu’en est-il de travailler hors de France pour le même travail ?

Dans un marché français moribond, dépasser les frontières apparaît de plus en plus comme une alternative solide pour qui souhaite se lancer à l’international.

Mais comment y parvenir quand on connait le rapport des Français avec les langues étrangères ?

J’ai eu l'occasion de passer un entretien réussi en anglais. Je peux donc en témoigner : passer un entretien anglophone n’est pas si insurmontable que ça, à condition de bien se préparer en amont.

Evidemment, tout dépend de ton niveau de départ, mais le plus important est de ne pas chercher à “gonfler” ton niveau artificiellement lors de l’entretien.

Tu ne peux pas tricher sur ton niveau d’anglais lorsque tu t’exprimes à l’oral.

Un natif n’est pas dupe.

Si tu es A1 ou A2, il faudra s’en doute un moment avant de pouvoir te lancer sans effort dans le grand bain.

Mais si tu es B1 ou B2, il est fort possible que tu aies de solides bases pour communiquer de manière claire avec des natifs sans rentrer dans des conversations trop pointues.

Cela ne suffit pas toujours dans certains domaines, mais c’est tout de même très encourageant pour la suite.

Hésiter ou bafouiller n’est pas grave, en soit. Les anglophones sont plutôt tolérants avec ça.

Ton anglais n’a pas besoin d’être parfait, il a surtout besoin d’être compris.

Durant 2 semaines, je me suis préparé pour mon entretien.

J’ai mis en place des exercices et des pratiques pour accélérer ma compréhension orale.

Voici mes astuces :

1. Récolter toutes les informations nécessaires lors de l’entretien préparatoire

J’ai eu la chance d’avoir un entretien préparatoire en français qui m’a permis de récolter toutes les informations sur le contexte de l’entreprise (conditions actuelles, enjeux, interlocuteurs clefs etc…)

Ceci m’a permis d’esquisser une trame pour le futur entretien.

Petite parenthèse :

Un entretien en anglais est un peu différent d’un entretien en français :

• L’échange est moins formel qu’en France, mais pas moins exigeant

• Il commence généralement par des anecdotes, se poursuit sur les aspects techniques et finit en questions-réponses

• Les anglais posent des questions alors que tu es en train de parler

• Il faut être concis et précis dans ses réponses

2. Créer un résumé de son CV en anglais à ChatGPT

J’ai demandé à ChatGPT de me fournir une version anglaise de mon CV pour un oral de 6 minutes où je présente mes expériences (niveau C1-C2 pour moi, mais tu peux choisir B1-B2 selon ton niveau)

J’ai ensuite enregistré le résumé à l’aide d’un enregistreur vocal et j’ai écouté et réécouté des audios en boucle pendant des heures.

3. Lire et écouter en même temps

C’est sûrement l’astuce la plus puissante.

Ecouter un texte en anglais et le lire en même temps augmente la vitesse de lecture et la collecte d’informations. Le contenu sera stocké dans plus d’endroits dans ton cerveau.
Donc j’ai écrit sur papier toute ma trame (mes expériences, ma formation, mais également des questions aléatoires afin d’être prêt à de multiples scénarios).

4. Répétition

Il y a quelque chose que tu vas remarquer rapidement une fois que tu auras enregistré ton texte à haute voix : en quelques jours, ton anglais va être plus fluide.

A force de répéter, tu ne vas (presque) plus y penser.

Cela va devenir naturel. Le cerveau est comme un muscle. Plus tu l’entraines, plus ta compréhension est facile.

Une heure par jour pendant dix jours suffit à faire des progrès significatifs en répétant ton texte à haute voix avec tes écouteurs.

5. Ne pas essayer de “gonfler” ton niveau

Comme je l’ai déjà dit, il est inutile d’utiliser des mots avancés pour démontrer ta maîtrise de la langue de Shakespeare.

Le plus important est de s’exprimer avec clarté.

Utiliser des mots de son niveau est la meilleure approche, non seulement pour être plus à l’aise, mais surtout pour les mémoriser.

Par contre, si tu connais déjà certains mots avancés, n’hésite pas à les glisser dans la structure de tes phrases !

Par exemple, j’ai demandé à ChatGPT de faciliter mon oral par des expressions simples et faciles à retenir :

• The key point here is / Le point clé ici est…

• Focusing on / Concentré sur…

• Whether or not…./ Que ce soit ou non

• The most important thing is… / La chose la plus importante est de…

Ces petites structures permettent de rester concis et précis.

6. Prendre en note chaque nouveau mot

J’ai l’habitude de noter chaque nouveau mot que je lis ou j’entends. La lecture est vraiment un levier pour apprendre le vocabulaire avancé. Je répète le mot plusieurs fois oralement et j’essaye de l’intégrer dans une nouvelle phrase afin de le mémoriser plus facilement.

Lire va te permettre de muscler ton vocabulaire.

7. S’entrainer avec ChatGPT Vocal

Bien sûr, ChatGPT ne remplace pas un humain, mais il a des avantages majeurs :

• Il est disponible 24H/24

• Il peut s’adapter à ton niveau ou te proposer un niveau plus difficile

• Il peut changer son accent et sa vitesse d’élocution à la demande (j’avais besoin d’un fort accent allemand et une vitesse élevée)

• Il te permet de briser les premiers blocages à l’oral sans crainte d’être jugé

C’est vraiment grâce à ChatGPT que j’ai pu progresser à l’oral de manière rapide.

8. Mon astuce personnelle

Etant très visuel, j’ai accroché l’ensemble de mes écrits sur un mur en face de moi.

Cette technique m’a permis de visualiser tous mes scénarios.

Une espèce de Mind Mapping, si tu préfères.

Cela a mis de l’ordre dans mes idées, m’a permis de dérouler mon discours plus simplement et surtout m’a évité d’hésiter !

Pour aller plus loin :

En 2016, pendant 6 mois, à raison de 3 heures par jour, je me suis investi sur l’apprentissage de l’anglais.

Les ressources que j’avais utilisées à l’époque sont toujours valables aujourd’hui.

Voici comment je procédais :

• Ecoute et d’analyse :

  Chaine Youtube : https://www.youtube.com/@LearnEnglishWithTVSeries

  Chaine Youtube : https://www.youtube.com/@engvidEmma

  Chaine Youtube : https://www.youtube.com/@LovelyEnglishStories

• Ecriture et grammaire :

  https://www.englishgrammar.org/

  https://learnenglish.britishcouncil.org/

Les résultats ont été bien plus impressionnants que durant toute ma scolarité.

Toutes ces ressources gratuites permettent de réellement progresser. Tu peux les combiner aux applications connues comme Duolingo ou Babel, si tu en as envie.

Je te conseille de combiner l’oral, l’écoute et l’écrit à égalité afin de ne pas être déséquilibré dans ta compréhension globale de l’anglais.

Ayant vécu en Irlande pendant plusieurs mois, je sais qu’apprendre une langue est long et qu’il faut pouvoir y consacrer du temps. Si tu ne t’y engages pas sérieusement en étant régulier et discipliné, tes résultats s’en ressentiront.

Par contre, il est indéniable que l’anglais t’ouvre des opportunités.

Ce n’est donc pas une compétence à acquérir en Nice-to-Have, c’est une arme secrète à dégainer en cas de marché difficile.

Unfair advantage, of course !

C’était Bruno pour te servir,

Tchô !

Et retrouve mon podcast ainsi que la bibliothèque de l’Agile Radiator ⬛ en accès illimité. D’ailleurs, quasiment tout y est écrit en anglais 😊 => Voir l’Agile Radiator

PS : Le code d’accès change tous les mois et te sera envoyé via cette newsletter. Si tu ne l’as pas encore reçu, assure-toi que le dernier mail n’est pas tombé dans les spams.

Je donne ensuite mon sentiment honnête sur la plateforme, ses avantages et inconvénients et en quoi elle reste pertinent dans une stratégie long terme.

N’hésite pas à liker et commenter afin de me dire ce que tu en penses !

C’était Bruno pour te servir.

Tchô !

Agile Radiator

28.01.2026

C’est officiellement le lancement de mon portail.

Une idée qui est devenue très concrète ces dernières semaines.

Hasard du calendrier, elle intervient en même temps que le démarrage de ma nouvelle mission à l’international dont je vous parlerai en podcast.

Mais revenons à nos moutons : Pourquoi l’Agile Radiator ?

Déjà, parce qu’après avoir écumé LinkedIn de long en large pendant un an, j’avais besoin de me créer MON OFFRE.

Oui, rien de très original, vous me pardonnerez…

Mais au-delà de l’offre, j’avais surtout besoin d’avoir quelque chose qui me ressemble et qui me différencie en même temps.

En DM, je recevais souvent la même demande :

“Bruno, as-tu des ressources que je puisse lire pour devenir un bon Scrum Master ?”

A cela, je n’avais souvent que des réponses banales :

“ Tu peux regarder la chaine Youtube de Scrum Life”

“ Tu peux lire le Scrum Guide, c’est gratuit”

En fait, je n’avais aucune idée de ce qui pouvait vraiment les intéresser.

Tout le monde est différent.

Et puis, j’ai repensé à mon propre parcours et comment j’avais débuté en tâtonnant, sans jamais savoir si j’allais dans la bonne direction.

Spoiler : je ne sais toujours pas ! Parce que…

Il n’y a pas de chemin parfait pour l’apprentissage de l’Agilité. Il y a des chemins.

Et que tu sois quelqu’un qui est intéressé par le rôle du Scrum Master ou même par le métier de Coach Agile en 2026, lire certains livres t’évitera pas mal d’écueils et de pièges dans lesquels tes prédécesseurs sont (déjà) tombés !

Pour ma part, certains livres ont été de véritables coups de cœur, des révélations :

“Coaching Agile Teams”, de Lyssa Adkins ou “Succeeding with Agile” de Mike Cohn m’ont indéniablement influencé.

Cela te permet de prendre non seulement du recul sur ton approche, mais également de la hauteur sur l’état de l’art.

Pour autant, ce qui me fait SURTOUT dire que la lecture a son importance, c’est bien le cataclysme provoqué par l’IA.

Un outil si puissant qu’il balaye tout sur son passage et bouscule toutes nos certitudes.

Les fondations, l’expérience, les échecs et les réussites.

Tout cela fait la richesse des Agilistes d’aujourd’hui avec leurs fissures, leurs fêlures.

Des aventures humaines, des partages sincères, des rires et des larmes.

Et l’IA ne pourra jamais remplacer ça, sauf si...

[C’est la CRIIISE ! Les Scrum Masters vont DISPARAITRE ! l’Agile est mort !]

Et non, la lecture n’est pas qu’un loisir, c’est une mine de savoir, un ancrage dans le présent dans un monde où tout va toujours plus vite, plus vite !

Bon, l’Agile Radiator, c’est une bibliothèque gratuite ouverte à tous, un podcast qui parle d’Agilité, de Tech et de prospection, MAIS… c’est surtout :

• Mon offre pour les dirigeants de PME, Start-ups, Scale-ups avec mon propre template, un livre blanc, un WhatsApp pour ne plus se quitter pendant 3 mois.

• Une problématique organisationnelle ? Je suis ton homme.

• Des soucis d’alignement Business IT ? Je suis ton homme.

• Des soucis avec des frameworks mal fichus ? Je suis ton homme.

Et tout cela, au même endroit. Et je suis encore en train d’itérer dessus comme un malade parce que je veux aller au bout de mon concept.

Bon, j’ai fini de te fatiguer, récupère ton CODE et va télécharger tes ressources gratuites dans les catégories suivantes :

• Lean

• Product Management

• Evidence Based Management

• Science du complexe

• Etc

Des lectures faciles, d’autres plus pointues. Il y en a pour tout les goûts !

Et le CODE valable un mois est :

AgileRadiator2026EtPlus

Écris-le tel qu’il est écrit car sinon, cela ne fonctionnera pas.

Dans un mois, il change, alors reste branché !

Direction l’Agile Radiator pour le taper et accéder aux premières ressources => ICI

Tu peux même rajouter les tiennes et on échange dessus quand tu veux.

La bibliothèque va s’étoffer de mois en mois, ça va devenir BIG.

Petit cadeau de bienvenue, mon premier podcast “Scrum et l’Agilité en crise ?” avec Damien Voces Olego est sorti il n’y a pas longtemps.

Si tu ne l’as pas encore écouté, je te le recommande vivement parce que c’est sans tabou ! => ICI

De grosses surprises arrivent pour 2026.

C’était Bruno pour te servir.

Tchô 😎

Des posts “Moi VS Eux”.

D’autres “Je VS Vous”.

Un contenu particulier. Une différenciation. Un positionnement clair.

Et à la fin, vient un indice de confiance. Une note. Une valeur perçue. Une donnée qualitative.

Le peuple sanctionne. Il s’engage, il rejette ou il ignore.

J’ai pu le lire, puis le dire comme beaucoup d’autres avant moi, l’AUTHENTICITE serait LA clef pour convertir de potentiels prospects en clients.

Et puis le recul m’a fait prendre conscience d’une chose :

Ne serait-ce pas une phrase creuse ? Un concept vague, marketé pour être facilement mémorisable, mais difficilement actionnable ?

Que cherche-t-on à dire ? Que nous ne serions, tous et toutes, que des menteurs pathologiques qui ne chercheraient qu’à se montrer sous notre meilleur jour sur LinkedIn ?

Des posts à notre avantage, des histoires dont nous sommes les héros, des succès romancés.

Un personal branding poussé à un tel point que même nos faiblesses ne seraient que manipulations et stratégies dans le seul et unique but d’attirer à nous l’empathie de l’audience.

Non, je ne peux croire que LinkedIn soit un endroit aussi sinistre, fourbe et fake.

Ce n’est pas vrai ! Je n’ai jamais croisé de telles choses, jamais !

…

Bon, trêve de plaisanteries sérieuses ! Reprenons.

Je me suis moi-même interrogé sur cette fameuse authenticité si convoitée et ce que j’ai pu découvrir est bien plus complexe qu’il n’y parait.

L’authenticité, c’est flou, c’est impalpable, c’est indicible.

Et derrière un écran, décerner la sincérité ou l’insincérité des gens relève du surnaturel.

Et pourtant, beaucoup sont ceux qui en parlent en long et en travers sur LinkedIn sans que personne ne définisse exactement ce que c’est et ce qu’il faudrait faire pour que cela transpire à travers nos contenus.

Oh si, il y a bien des gens pour dire de poster des photos intimes, de parler de ses échecs, d’être aussi transparent que dans un journal intime…

Mais cela ne dit toujours pas si cela est perçu comme de l’authenticité ou comme un simulacre.

Il n’existe pas de communication authentique ou inauthentique en soi, seulement des communications interprétées comme telles

Sur LinkedIn, certains apprécient afficher les échanges épineux qu’ils ont pu avoir avec leurs prospects comme autant de preuves d’une prospection besogneuse.

“ Ah, vous voyez ? Kevin ne comprend pas que je ne lui propose pas mes services, seulement un appel découverte. Il voit le mal partout. ”

Curieuse manière d’attirer ceux qui pourraient être nos clients avec une empathie proche du néant.

Ce qui est à souligner c’est que, encore une fois, le fond du problème reste la remise en question de la sincérité.

La base de la confiance, la puissance de la marque.

En faisant une analogie simple, je peux oser comparer LinkedIn avec… Le Bon Coin !

Il s’agit de deux styles d’approche de la vente distincts et pourtant très semblables.

J’ai vendu ma moto sur Le Bon Coin.

Le gars n’a pas tergiversé. On a négocié le prix et l’affaire était réglée.

L’aspect transactionnel était le seul sollicité. L’authenticité n’avait aucun impact.

La vente était rapide !

Mais sur LinkedIn, c’est une autre histoire… Un mot revient souvent : le social selling.

C’est la vente via les réseaux sociaux. Plus longue, plus complexe, pas garantie.

Et sur LinkedIn, le temps devient un allié ou un ennemi.

Parce qu’ici, on ne vend pas une moto. On vend... soi.

Et c’est là que le bât blesse.

Sur Le Bon Coin, personne ne se demande si le vendeur est “authentique”. On regarde les photos, l’état du produit, le prix. Point.

Sur LinkedIn, on scrute. On analyse. On jauge.

“Est-ce qu’il est vraiment expert ou juste bon en storytelling ?”

“Est-ce qu’elle a vraiment vécu ce qu’elle raconte ou c’est du ChatGPT bien emballé ?”

“Est-ce que ce témoignage client est réel ou fabriqué de toutes pièces ?”

Le doute s’installe. La méfiance rôde.

A partir du moment où tu es conscient que tu vas publier telle ou telle chose, la spontanéité n’existe plus et le bouton “Publier” te le rappelle à chaque fois

Chaque mot est pesé. Chaque phrase est relue. Chaque publication est optimisée. Tu as le temps de te relire 10 fois avant d’enfin appuyer sur “Publier”.

Et quand cela est fait, recevoir un procès d’insincérité en retour est pour le moins… déstabilisant !

Alors, oui, sachant qu’il est impossible de détecter l’authenticité et que, de toute façon, les gens y croient de moins en moins, la vraie question n’est donc pas “comment être authentique sur LinkedIn ?”, mais plutôt : “quelle version de moi-même suis-je prêt à montrer, et pourquoi ?”

Parce qu’entre le mensonge total et la vérité absolue, il existe une zone grise.

Celle de la sincérité choisie. On ne dit pas tout. On ne montre pas tout. Mais ce qu’on montre, on le pense vraiment. Ce qu’on dit, on le croit sincèrement. Ce qu’on partage, on l’assume pleinement.

Pas de double discours. Pas de contradiction flagrante entre le LinkedIn et le réel. Juste une curation intelligente. Un cadrage maîtrisé. Une mise en scène honnête.

C’est peut-être ça, finalement, la seule forme d’authenticité viable sur LinkedIn.

Pas la transparence totale qui confine à l’exhibitionnisme. Mais la cohérence assumée qui inspire confiance.

Je profite de cette newsletter pour vous remercier chaleureusement.

OUI, TRES CHALEUREUSEMENT !

Car vous êtes plus de 220 à me lire et je suis heureux de vous annoncer que le 28 janvier, la bibliothèque de l’Agile Radiator sera ouverte avec un accès à vie via un mot de passe envoyé le jour même.

J’ai hâte de vous y retrouver pour partager, échanger et surtout progresser dans le freelancing, l’Agilité, la prospection ! 😀

Découvrir l’Agile Radiator

On entend souvent dire que plus on a d’abonnés, plus on a d’opportunités sur LinkedIn.

Cette croyance, réelle ou supposée, modifie profondément la perception qu’ont certaines personnes sur les créateurs de contenu.

Leur valeur perçue grandit proportionnellement à leur nombre d’abonnés.

Le nombre d’abonnés devient alors une preuve sociale, un gage d’expertise, une preuve de qualité à part entière.

SAUF QUE… Ce n’est pas si simple.

Cette croyance est-elle fondée ?

Comme j’ai pu déjà le dire dans mes précédents chapitres, cette course à la viralité amène des effets pernicieux dont voici quelques exemples :

1. Des experts qui ne postent que très peu d’expertise

Publier souvent ne signifie pas forcément publier utile.

On dit souvent qu’il faut créer du contenu plus personnel pour se connecter à son audience et paraitre “authentique”. Sauf qu’écrire sur sa vie n’est pas forcément pertinent dans le monde professionnel.

Non pas qu’il faille faire du corporate à tout prix, mais il ne faut pas non plus transformer son profil professionnel en journal intime.

Pourquoi ? Parce qu’il ne faut pas diluer sa proposition de valeur.

Il est déjà assez dur de se positionner sur sa niche pour ne pas, en plus, saupoudrer cela par des posts qui détourneraient l’attention sur ce qui est réellement important :

LA VALEUR !

Je vois parfois des posts malaisants : des photos intimes postées à l’hôpital ou des photos de vacances très personnelles…

Et vouloir maintenir un volume d’impressions élevé n’est pas un argument pour écrire tout et n’importe quoi avec n’importe quel selfie sans lien avec le sujet du post.

Comme les posts plus techniques ne sont pas mis en avant par l’algorithme, certains préfèrent poster simplement une anecdote sur eux-mêmes avec leur photo de vacances.

Et parfois, ce genre de posts “faciles” prend le pas sur des posts plus réfléchis.

Ce qu’on oublie souvent lorsque l’on poste trop : ton potentiel prochain recruteur/client peut te lire, ou être susceptible de te lire.

Alors, on peut toujours s’exposer, mais il faudra accepter que l’on peut se faire blacklister par un recruteur/client.

Certains proclameront que cela permet de filtrer naturellement leur cible et que leur positionnement s’affirme (et s’affine).

Mais je ne partage pas cet avis : pour moi, la stratégie du Moi VS Tous est une stratégie risquée à double tranchant.

A court terme, c’est différenciant et ça permet de retenir l’attention.

A long terme, ça ternit forcément ton image perçue.

Pourquoi ?

Parce que les gens retiennent plus longtemps les émotions négatives que les émotions positives et donc des posts clivants ou malaisants laisseront une impression… Désagréable

2. Un algorithme qui favorise plus la viralité que la valeur réelle

C’est un fait, les posts techniques sont moins poussés que des posts plus légers.

Maintenant, est-ce un drame ?

Le reach s’effondre et tout le monde voit son nombre d’impressions baisser.

Mais au-delà de cette tendance générale, il y a un problème structurel : l’algorithme récompense ce qui génère de l’engagement rapide. Les réactions émotionnelles, les débats, les prises de position tranchées.

Pas nécessairement ce qui apporte de la valeur à long terme.

Résultat ? On se retrouve avec des créateurs qui adaptent leur contenu non pas à leur expertise, mais aux caprices de l’algorithme.

Ils écrivent pour plaire à la machine, pas pour servir leur audience.

Et c’est là que le piège se referme : plus on cherche la viralité, plus on s’éloigne de son positionnement initial. On devient dépendant de mécaniques qui ne nous appartiennent pas, la fameuse “schizophrénie”.

Le paradoxe ? Ces mêmes créateurs se plaindront ensuite d’attirer une audience qui ne correspond pas à leur cible.

Mais comment pourrait-il en être autrement quand on construit sa stratégie sur des posts conçus pour plaire au plus grand nombre plutôt qu’au bon nombre ?

Je continue à poster des posts techniques qui visent une niche, malgré tout.

Pourquoi ?

Je me moque du nombre d’impressions depuis mon premier jour de publication.

Cela ne m’a jamais motivé à écrire plus.

Ce qui m’anime, c’est d’appuyer mon propos, de partager mes idées avec les autres, même si cela peut être clivant.

Si j’avais voulu devenir viral, il m’aurait suffit de m’inscrire à un POD ou de payer une formation à 3000 e, pour ensuite faire une capture écran de mon nombre d’impressions/abonnés et me gargariser que j’ai fait tout ça à la seule force de mon clavier (la bullshit economy).

Mais j’avais envie de me regarder dans la glace et de ne pas prendre mon audience pour des moutons.

L’algorithme n’est pas ton ennemi. Mais en faire ton unique boussole, c’est renoncer à toute stratégie de positionnement cohérente.

3. Une audience qui n’est pas ta cible

Avoir 50 000 abonnés, c’est impressionnant sur le papier.

Mais si 45 000 d’entre eux ne sont pas ta cible, quelle est réellement la valeur de cette audience ?

Pour moi, ça sert à RIEN.

Voilà le problème majeur de la course aux abonnés : on finit par construire une communauté hétéroclite, attirée par des contenus viraux qui n’ont rien à voir avec ton expertise réelle.

Tu deviens populaire, mais pas pertinent.

Et quand vient le moment de convertir cette audience en opportunités concrètes, le décalage devient évident. Les personnes qui te suivent ne sont pas celles qui ont besoin de tes services ou de ton expertise.

Elles sont là pour le divertissement, pas pour la valeur professionnelle.

Certains me diront : “Oui, mais au moins j’ai de la visibilité.”

La visibilité sans pertinence, c’est du bruit. Rien de plus.

Mieux vaut 500 abonnés qualifiés qui correspondent exactement à ta cible que 10 000 abonnés divers qui ne feront jamais appel à toi.

Parce qu’au final, ce qui compte, ce n’est pas d’être vu par beaucoup. C’est d’être vu par les bonnes personnes.

Et cette distinction, beaucoup l’oublient dans leur quête effrénée de croissance.

4. La pertinence est contextuelle

Un créateur avec 100 000 abonnés n’est pas forcément plus pertinent qu’un créateur avec 2 000 abonnés.

Tout dépend du contexte.

Si tu cherches un expert en fiscalité des startups deeptech, le consultant spécialisé avec 1 500 abonnés triés sur le volet sera infiniment plus pertinent que l’influenceur business généraliste suivi par des dizaines de milliers de personnes.

La pertinence ne se mesure pas au volume. Elle se mesure à l’adéquation.

Et c’est précisément ce que le culte du nombre d’abonnés fait oublier : la valeur d’une expertise ne se dilue pas dans la masse, elle se concentre dans la précision.

Quelqu’un qui parle à tout le monde ne parle à personne en particulier.

À l’inverse, quelqu’un qui s’adresse à une niche spécifique, même restreinte, crée une connexion réelle avec son audience.

Cette connexion, c’est ce qui transforme un abonné en client, un lecteur en partenaire, une impression en opportunité concrète.

Mais cette nuance échappe à beaucoup. Parce qu’elle ne se voit pas. Elle ne s’affiche pas fièrement sur un profil. Elle ne nourrit pas l’ego.

Pourtant, c’est elle qui fait toute la différence entre une présence LinkedIn stratégique et un simple exercice de vanité numérique.

5. Poster ne suffit pas

Publier du contenu régulièrement, c’est bien.

Mais si on s’arrête là, on passe à côté de l’essentiel.

Parce que LinkedIn n’est pas une plateforme de broadcast. C’est un réseau social. Le mot est important : réseau.

Et un réseau, ça se cultive. Ça s’entretient. Ça se nourrit d’interactions réelles, pas seulement de publications unilatérales.

Certains créateurs pensent qu’il suffit de poster trois fois par semaine pour que les opportunités tombent du ciel. Que la visibilité seule fera le travail.

Sauf que non.

Les vraies opportunités naissent rarement d’un simple post viral. Elles naissent des conversations qui suivent. Des messages privés. Des échanges dans les commentaires. Des relations construites dans la durée.

Poster sans interagir, c’est comme distribuer des cartes de visite dans la rue sans jamais adresser la parole à personne.

Tu touches des gens, certes. Mais tu ne crées aucun lien.

Et sans lien, pas de confiance. Sans confiance, pas d’opportunité.

Alors oui, publie. Mais prends aussi le temps de répondre, de commenter, de créer du dialogue avec ceux qui te lisent.

Parce qu’au final, ce n’est pas le nombre de posts qui compte. C’est la qualité des relations que tu construis à travers eux.

Je te donne un exemple concret : depuis plusieurs semaines, je demande systématiquement aux personnes qui veulent se connecter à moi pourquoi elles le font.

Dans la majorité des cas, ce sont mes posts qui les intéressent.

Pourtant, elles ne les likent jamais.

Grâce à un contenu pertinent, c’est plus facile pour moi d’engager la conversation sur mon offre.

Mes posts me servent de point d’entrée, ils ne sont jamais une finalité.

Je le répète : la messagerie et les vues de profil sont les seules métriques valables sur LinkedIn - avec l’engagement silencieux.

Conclusion

Le nombre d’abonnés sur LinkedIn est devenu une métrique de vanité.

Un chiffre qui rassure l’ego mais qui ne dit rien de la valeur réelle d’un créateur de contenu.

Pourtant, cette obsession persiste. Parce qu’elle est visible. Parce qu’elle se compare facilement. Parce qu’elle donne l’illusion d’une réussite mesurable.

Mais derrière cette façade, la réalité est souvent décevante : une audience diluée, un positionnement flou, des opportunités qui ne se concrétisent jamais.

Alors, faut-il abandonner LinkedIn pour autant ?

Non.

Il faut simplement revenir à l’essentiel : la clarté de son positionnement, la qualité de son contenu, la pertinence de son audience.

Arrêter de courir après l’algorithme et commencer à construire une présence cohérente avec ses objectifs professionnels.

En 2025, on vend l’acquisition rapide sur LinkedIn, on vend le nombre d’abonnés en 6 mois, on vend les relances clients en DM, on vend les systèmes automatisés gonflés à l’IA.

Bref, on vend des raccourcis qui ne reposent sur aucune fondation solide, aucune base communautaire émotionnellement connectée… Mais qui font gagner un maximum d’argent à ceux qui les vendent.

L’énergie est dispersée alors qu’elle devrait plutôt être concentrée sur la fidélisation et le renforcement de l’engagement.

Parce qu’au final, ce qui compte, ce n’est pas d’être suivi par des milliers de personnes.

C’est d’être reconnu par les bonnes.

Et ça, aucun compteur d’abonnés ne pourra jamais le mesurer.

D’ailleurs, je compte exposer toute ma stratégie LinkedIn dans l’Agile Radiator.

• Comment j’ai fait pour acquérir une base de 300 recruteurs et obtenir des opportunités sur le marché rouge chaque semaine

• Comment je vais me lancer sur le marché bleu via LinkedIn

Mais l’Agile Radiator, c’est bien plus que ça.

J’en avais marre de m’adresser à la fois à des dirigeants d’un côté et à des Agilistes de l’autre sur LinkedIn

Je voulais réunir les 2 dans un même espace afin de réduire ma propre charge mentale.

De là est venue l’idée d’Agile Radiator.

Il s’agit d’un portail où je vais pouvoir m’adresser directement aux dirigeants (CEO, CTO, Managers), mais également à vous, mes abonnés.

Dans la newsletter tu auras désormais :

• Mes insights sur LinkedIn

• Mes billets sur l’Agilité parce que LinkedIn c’est très court

• Des ressources gratuites dans la bibliothèque de l’Agile Radiator pour devenir un Agiliste érudit (ça vaut de l’or, de nos jours)

• Le code d’accès à ces ressources

• Et les podcasts sur l’Agilité, la prospection, l’entrepreneuriat etc avec des invités triés sur le volet

Bref, de nombreuses raisons de rester abonné ici car le meilleur arrive 🔥

J’en dirais plus dans la prochaine newsletter où je t’expliquerai tout sur ce changement d’entité.

Alors, joyeuses fêtes et on se retrouve en 2026 pour le lancement ! 😀

Bruno

Hello tout le monde,

Cela faisait un moment que je n’avais pas envoyé de newsletter afin de poursuivre ma série sur mon bilan LinkedIn.

Désolé, j’ai eu pas mal de boulot et d’imprévus.

Bref, je suis en train de réparer cet affront envers vous…

La dernière fois, j’avais dit que j’aborderai le sujet des haters sur LinkedIn.

Finalement, avec le recul, j’ai réalisé que je n’étais pas inspiré par ce thème.

J’ai donc trouvé une nouvelle idée à traiter que je trouve bien plus intéressante : pourquoi, en 2025, il est si difficile de “percer” sur LinkedIn.

Et surtout, pourquoi ChatGPT n’est pas à blâmer dans toute cette histoire !

La question est à la fois intéressante et complexe.

Intéressante parce qu’elle nous ramène à notre rapport aux réseaux sociaux, comment on les influence et comment ils nous influencent dans notre manière d’interagir numériquement entre nous.

Complexe, parce que, malheureusement ou heureusement, c’est LinkedIn qui reste maitre du jeu.

Peu importe ce qu’on dit, ce qu’on fait ou ce qu’on constate, la vérité, c’est qu’on interprète toujours au lieu d’affirmer et qu’on ne peut rien faire d’autre que de suivre ou ne pas suivre les dernières mises à jour de l’algorithme.

Mais il y a quand même un grand MAIS.

Tu, moi, nous, avons notre part de responsabilité.

S’il est si difficile de percer sur LinkedIn en 2025, c’est avant tout notre faute.

1. Un manque de persévérance

Cela fait 1 an que je poste de manière très irrégulière sur LinkedIn.

Autrement dit, sur l’échelle de la durabilité, une goutte d’eau.

Et si mes performances sont honorables sans être incroyables, je ne le dois qu’à mon manque de régularité.

Et il y a beaucoup de personnes dans ce cas.

Elles ne vont pas s’impliquer de manière à avoir des résultats solides.

Elles vont poster de temps en temps, puis constater que leur visibilité ne décolle pas et se décourager au bout de quelques mois.

Comme pour le sport, beaucoup souhaitent des résultats rapides sans avoir réfléchi à des objectifs à atteindre.

On teste et on se dit pourquoi pas ? Sauf que la motivation redescend très vite puisque les habitudes ne sont pas ancrées.

On doute, on se lasse et puis on se dit : “ Ce n’est pas fait pour moi. J’arrête.”

En clair, publier n’est pas le compliqué, c’est la régularité.

Voilà, pour moi, la première difficulté.

2. Ecrire n’est pas facile

Ecrivains, journalistes, poètes… Ils le reconnaitront tous : écrire n’est pas facile.

Et écrire régulièrement l’est encore moins.

Il ne s’agit pas juste d’écrire, il faut raconter une histoire, conscientiser son écriture, affiner sa plume afin que l’on ressente le “parler vrai”, malgré la barrière numérique.

Pendant 6 ans, j’ai écrit sur une plateforme d’écriture. C’est une passion.

Malgré cela, je dois reconnaitre que c’est très ingrat.

Il y a notre pensée, notre manière de l’exprimer par l’écrit et la perception des lecteurs en nous lisant.

Ce sont trois contraintes qu’il faut surmonter à chaque fois que l’on publie sur LinkedIn.

Idée => Message => Réception.

Ces 3 points vont faire germer des milliers de possibilités.

Pour qu’un post fonctionne, ces 3 points doivent tous être au vert.

Malheureusement, tout part de l’idée et si celle-ci n’est pas originale ou travaillée, elle tombera dans l’oubli.

Il y a trop d’idées identiques sur LinkedIn. Les gens ne prennent pas le temps de chercher des idées novatrices sur la plateforme (et je m’inclus volontiers dans le lot).

Par paresse, par manque de temps, mais surtout, par manque de compréhension des codes.

Il ne s’agit pas de réinventer la roue car toutes les histoires ont déjà été écrites.

Ce qui fera la différence ? Toi, tes opinions, tes valeurs, tes principes et ton écriture.

Et si ChatGPT peut dépanner en proposant des idées, il faudra tout de même trouver un angle différenciant, une touche humaine qui harmonise l’ensemble en le rendant authentique.

En résumé, il ne s’agit pas d’écrire de manière scolaire comme au BAC de philo.

Il s’agit de se mettre dans la peau des lecteurs et c’est quelque chose que peu de personnes font réellement.

Mettre sa peau sur la table, c’est difficile.

A toi de trouver le bon alignement entre ce que tu es et ce que tu postes.

4. L’océan rouge de LinkedIn

Il y a de plus en plus de monde qui poste sur LinkedIn.

Ce n’est un secret pour personne.

Qui dit plus de monde, dit plus de concurrence et plus de difficultés à sortir du lot.

L’algorithme booste moins tous ces posts qui l’alimentent, à quelques exceptions près.

L’analyse du post va maintenant au-delà de la simple réception de likes. Le post sera diffusé en fonction de sa pertinence par rapport à ta cible.

L’algorithme va absolument TOUT analyser : cohérence, expertise, commentaires, enregistrements, likes…

Percer devient alors une course à l’attention ou chacun redouble d’effort pour exister, quitte à lasser l’audience.

Et ce n’est pas toujours très joli à voir…

5. Bâtir une communauté, c’est long…

On peut comparer ça à l’investissement en Bourse.

Investir demande du temps, beaucoup de temps.

Les résultats ne sont pas immédiats et il peut y avoir une frustration latente.

LinkedIn, c’est pareil. Il faut pouvoir y consacrer du temps chaque semaine tout en restant authentique.

Et le pire, c’est qu’on ne sait absolument pas si tout cela servira à quelque chose dans 5 ans.

Je comprends que beaucoup soient tentés d’abandonner devant la montagne à gravir.

Ce qu’il faut se dire, c’est que des connexions professionnelles et sincères subsistent toujours sur cette plateforme quand on y prête attention.

6. Les posts et commentaires IA n’ont pas amélioré les choses

On peut dire qu’une partie des utilisateurs s’est sabotée, dans le sens où beaucoup ont pensé que l’IA allait pouvoir les remplacer et écrire à leur place.

L’automatisation est tentante, mais manque cruellement d’authenticité.

Penser que tout n’est que transactionnel et mettre de côté l’humain est antinomique au principe même d’un réseau social.

Oublier cela est, selon moi, une erreur monumentale.

La culture de l’instant peut faire penser que ChatGPT peut te remplacer, en réalité, tu creuses la tombe de ton propre personal branding en l’utilisant à outrance.

Personnellement, je l’utilise comme un assistant, pas comme mon double numérique.

Les gens comprennent de mieux en mieux la supercherie.

Ne deviens pas paresseux.

Prends ChatGPT comme ta béquille, pas comme ton stagiaire bénévole.

7. LinkedIn te vend de l’attention

LinkedIn, comme toute entreprise, cherche à être rentable.

Et pour cela, tous les moyens sont bons, y compris faire payer les utilisateurs pour gagner en visibilité comme le fait déjà Facebook ou Instagram.

L’abonnement premium le faisait déjà, il est désormais possible de booster ses posts en payant.

Il y a de fortes chances que l’algorithme se montre de plus en plus contraignant à l'avenir, ce qui ne présage rien de bon pour les créateurs de contenu.

Que faire, alors ?

Rien… ou presque !

Il faut bien choisir ses combats et c’est bien sur la qualité de tes posts que tu peux agir.

Voilà ce que j’applique pour moi :

• Je me force à rester simple et concis afin de répondre au format LinkedIn

• Je me relis

• Je fais en sorte que mon langage écrit ressemble à mon langage parler tout en restant professionnel

• Je me relis encore, une fois avoir posté

• J’analyse toujours mes posts les plus performants afin de les décortiquer

• Je répète et répète encore toute cette méthode.

Voilà, c’est à peu près tout. Rien de magique.

Malgré tout ce que j’ai pu dire au-dessus, je pense toujours que publier sur LinkedIn est un très bon levier d’exposition.

Alors, prêt.e à sauter le pas ?

C’était Bruno pour te servir.

Tchô !

Aujourd’hui, j’ai envie de te régaler. Pas de blabla, que de l’actionnable.

Que tu sois freelance ou CDI, savoir prospecter devient une compétence incontournable.

Il n’y a pas 36000 façons de progresser. Il faut se lancer.

Et c’est ce que j’ai fait fin 2024.

Après 10 mois à expérimenter et à apprendre, je te donne les 7 hacks qui m’ont permis de construire un vivier (toujours en évolution) :

• 1. Messagerie LinkedIn

La messagerie LinkedIn est une mine d’or et son historique remonte des années en arrière. J’ai pu retrouver des conversations avec des recruteurs de plus de deux ans.
J’ai entamé les premières prises de contact de cette manière.

• 2. Tableau Excel

Oui, traditionnel et pas très sexy. Mais c’est bien dans un Excel que je note chaque interaction avec un recruteur (téléphone, email, entreprise etc.) mais également les derniers appels et les opportunités avec une note de classement.

Une note de classement ? Mais à quoi ça sert ?

Et bien, tout comme les recruteurs notent les candidats, je note les recruteurs et leur attribue une note selon qu’ils trouvent une opportunité ou non et selon la qualité de ma relation avec eux.

Ce dernier point est très important pour la suite de la lecture.

• 3. Dossier de compétences

La plupart des gens mettent leur CV sur les différents job boards. C’est une erreur. C’est le dossier de compétences (un document de 5 à 15 pages) qu’il faut mettre en ligne. Il détaille chacune des missions, les actions et les résultats et est beaucoup plus convaincant qu’un simple CV.

• 4. ChatGPT

J’ai transformé ChatGPT en chasseur de têtes et tu peux faire pareil très facilement.

J’ai déjà expliqué le modop détaillé avec ChatGPT.

Tu le retrouves ici .

• 5. Recruiter Lite

Et ici pour Recruiter Lite.

6. Cold call

Pour récupérer un téléphone, il y a deux outils en version gratuite disponibles : Kaspr et Lusha.

Tu as les deux méthodes :

• Tu peux ajouter un CSV contenant les urls des profils LinkedIn dont tu veux obtenir les cordonnées (numéro + email) sur Kaspr (la version gratuite

• Tu peux directement taper le nom + prénom du profil dont tu souhaites obtenir les cordonnées (numéro + email) sur Lusha (la version gratuite te droit à un peu de crédit renouvellé mensuellement)

Pour pouvoir ouvrir un compte, il te faut créer une email professionnelle, donc ni hotmail, ni Gmail, ni yahoo…

Tu peux créer en quelques clics ton email sur le site Hostinger avec un nom de domaine.

Il ne te reste plus qu’à récupérer les numéros et à décrocher ton téléphone.

7. Les posts LinkedIn (inbound)

Les posts LinkedIn ciblés avec un call-to-action sont toujours efficaces. Ce ne sont pas ceux qui vont rapporter le plus de likes ou de commentaires, mais il y a toujours un recruteur qui me contacte suite à un de mes posts. Cela permet également de ne pas être oublié.

Astuce : trouve ton style, ton ton et sois décalé dans l’angle que tu utilises dans tes posts.

Voilà, j’espère que ces quelques hacks vont te permettre de booster ta prospection.

Ce qui compte vraiment, c’est d’être régulier et de répéter les actions chaque semaine.

N’hésite pas à m’envoyer un DM si tu as besoin de précisions :-)

C’était Bruno Carlyle pour te servir,

Tchô