#aufinalavecdurecul
Méthodologies projet : le grand théâtre des étiquettes sans le spectacle
Agile, SAFe, Scrum, Shape Up, LeSS : quand le nom de la méthode devient plus important que la méthode elle-même — et comment reconnaître une organisation qui n’en a tout simplement pas.
Il existe un test simple pour savoir si une organisation applique vraiment une méthodologie projet ou si elle en porte simplement le t-shirt.
Posez la question suivante à cinq personnes différentes dans l’équipe IT : comment vous organisez-vous pour livrer un projet ?
Si vous obtenez cinq réponses cohérentes, décrivant les mêmes processus, les mêmes rituels, les mêmes responsabilités — avec peut-être des nuances sur les détails — vous avez affaire à une organisation qui a une méthode réelle.
Si vous obtenez cinq réponses différentes, dont certaines mentionnent Agile, certaines Scrum, certaines on s’adapte selon les projets, et une qui évoque vaguement des sprints sans savoir vraiment à quoi ça sert — vous avez affaire à une organisation qui a une étiquette. Pas une méthode.
La différence entre les deux est plus répandue qu’on ne le croit. Et elle a des conséquences très concrètes sur les projets, les équipes et les budgets.
Le marché des étiquettes méthodologiques : une inflation incontrôlée
Depuis que l’Agile Manifesto a été signé en 2001 par dix-sept développeurs dans un chalet d’Utah, le terme agile est devenu l’un des mots les plus utilisés — et les plus vidés de sens — de l’écosystème IT.
Il a d’abord désigné une philosophie de développement logiciel fondée sur quatre valeurs et douze principes. Puis il est devenu un framework (Scrum), puis plusieurs frameworks (Kanban, XP, SAFe, LeSS, Shape Up, Nexus, DAD — la liste continue de s’allonger). Puis il est devenu un adjectif applicable à n’importe quoi : une réunion agile, une organisation agile, une stratégie agile, un budget agile. Puis il est devenu une valeur d’entreprise inscrite dans les rapports annuels, entre innovation et excellence opérationnelle.
À ce stade, agile ne veut plus dire grand-chose. Et c’est précisément le problème. Chaque fois qu’un terme devient suffisamment populaire pour entrer dans le vocabulaire managérial généraliste, il se vide de sa substance opérationnelle. Il reste le mot, sans le contenu. L’étiquette, sans la méthode.
Taxonomie des fausses méthodologies — un guide de terrain
Il existe plusieurs variétés de méthodo-fantômes, chacune avec ses caractéristiques propres. Les reconnaître permet de ne pas se laisser impressionner par le vocabulaire.
L’Agile de façade
C’est la variété la plus répandue. Elle se caractérise par la présence de tous les artefacts visibles de Scrum — des sprints de deux semaines, un backlog, des daily stand-ups, un Scrum Master et un Product Owner avec les titres sur la carte de visite — et l’absence de ce qui fait fonctionner la méthode dans la réalité.
Les sprints existent, mais leur périmètre est modifié en cours de route à chaque demande de la direction. Le backlog existe, mais personne ne l’a vraiment priorisé depuis trois mois. Les daily stand-ups existent, mais ils durent quarante-cinq minutes et ressemblent davantage à des réunions de reporting qu’à des synchronisations d’équipe. Le Product Owner existe, mais il n’a pas réellement l’autorité pour prendre des décisions sur le produit.
Le résultat : une organisation qui a tous les coûts de l’Agile (les rituels, la réorganisation en squads, les outils de suivi) et aucun de ses bénéfices (la réactivité, l’amélioration continue, la livraison de valeur régulière).
Le SAFe qui cache un cycle en V
SAFe — Scaled Agile Framework — est à l’Agile ce que le SUV est à la voiture de sport : ça en emprunte l’esthétique, mais la conduite est fondamentalement différente. SAFe est une réponse au problème réel de mise à l’échelle de l’Agile dans les grandes organisations, avec ses PI Planning, ses Agile Release Trains et sa gouvernance multi-niveaux.
Dans beaucoup d’organisations, SAFe est devenu le véhicule présentable pour maintenir un cycle en V classique sous une terminologie agile. Le PI Planning ressemble à une messe trimestrielle où les équipes décrivent ce qu’elles vont faire pendant les trois prochains mois. Ce qui n’est pas très différent d’un planning classique, si ce n’est que c’est nettement plus long et qu’il y a des post-its.
Le Kanban sans limites
Le Kanban est une méthode de gestion du flux fondée sur un principe simple et puissant : limiter le travail en cours (WIP) pour améliorer le débit et identifier les goulots d’étranglement. Dans sa forme pure, c’est un outil remarquablement efficace.
Dans sa version dégradée — la plus courante — le Kanban est un tableau avec des colonnes et des cartes qui s’accumulent dans la colonne En cours sans jamais vraiment se terminer. Les limites de WIP, qui sont le coeur de la méthode, ne sont pas appliquées parce que personne ne veut dire non à une nouvelle tâche. Résultat : le tableau visualise le chaos sans le réduire. C’est un thermomètre qu’on a confondu avec un traitement.
Le Shape Up mal digéré
Shape Up est la méthode développée par Basecamp qui a rencontré un succès certain dans les entreprises produit ces dernières années. Elle propose des cycles de six semaines, des équipes autonomes, et une discipline rigoureuse sur la définition des problèmes à résoudre avant de commencer à les résoudre.
Sa version mal digérée ressemble à ceci : on prend les six semaines (parce que c’est plus long que les sprints de deux semaines, ce qui arrange tout le monde), on les appelle Shape Up cycles, on abandonne les daily stand-ups (parce que Shape Up n’en préconise pas, et ça arrange les managers qui les trouvaient chronophages), et on continue de travailler exactement comme avant — juste avec des cycles plus longs et sans réunions de synchronisation. Le résultat est généralement une organisation moins coordonnée, pas plus autonome.
La méthodo sur mesure qui est en réalité l’absence de méthodo
La plus difficile à détecter, parce qu’elle se présente comme une sophistication. Nous avons développé notre propre approche, adaptée à notre contexte. Nous sommes pragmatiques, nous prenons ce qui fonctionne dans chaque méthode. Nous n’appliquons pas un framework dogmatiquement.
Ces phrases peuvent décrire une organisation mature qui a effectivement internalisé les principes de plusieurs méthodes et les applique avec discernement. Elles peuvent aussi décrire une organisation qui n’a jamais vraiment appliqué aucune méthode, qui change d’approche à chaque projet selon la préférence du chef de projet, et qui appelle ça de l’adaptabilité.
Pour distinguer les deux : demandez comment les décisions de priorisation sont prises. Une organisation qui a une vraie méthode, même sur mesure, a une réponse précise. Une organisation sans méthode réelle a une réponse vague sur le consensus et la discussion.
Pourquoi les étiquettes se substituent aux méthodes
Ce phénomène de rebranding méthodologique n’est pas le fruit du hasard ou de la mauvaise foi. Il a des causes structurelles qu’il faut comprendre pour ne pas simplement les condamner.
La pression de la modernité
Toute organisation IT qui se respecte doit aujourd’hui se déclarer agile. C’est une exigence implicite des recrutements, des appels d’offres, et des discours de direction. Cette pression crée une incitation puissante à adopter les termes sans nécessairement adopter les pratiques.
La résistance organisationnelle au vrai changement
Appliquer vraiment l’Agile dans une grande organisation nécessite de changer des choses que beaucoup de personnes ne veulent pas changer. Donner de l’autonomie réelle aux équipes implique que les managers intermédiaires lâchent du contrôle. Prioriser rigoureusement le backlog implique de dire non à des demandes. Livrer par petits incréments testables implique d’accepter une phase d’imperfection visible. Ces changements sont difficiles politiquement. Adopter le vocabulaire sans les pratiques permet d’éviter ces frictions.
Le marché des consultants et des certifications
Il existe un écosystème entier d’organisations qui vivent de la vente de formations, de certifications et de missions de conseil autour des frameworks agiles. Cet écosystème a un intérêt structurel à la multiplication et à la complexification des frameworks. Plus il y a de certifications à passer, de niveaux à atteindre, de rôles à créer, plus le marché est grand. SAFe compte aujourd’hui plus de vingt rôles certifiables. C’est autant de formations à vendre.
La confusion entre adoption et transformation
Beaucoup d’organisations confondent l’adoption d’un vocabulaire ou d’outils avec la transformation culturelle que la méthode est censée produire. On installe Jira et on pense être agile. On forme les équipes à Scrum et on pense avoir changé la façon dont les décisions sont prises. L’outil ou le framework est nécessaire mais pas suffisant — et cette différence est rarement expliquée clairement par ceux qui ont intérêt à vendre l’adoption.
Ce que révèle l’absence de méthode réelle
Une organisation sans méthode projet réelle n’est pas seulement moins efficace dans ses livraisons. Elle révèle quelque chose de plus profond sur son rapport à la gouvernance, à la responsabilité et au leadership.
Une méthode réelle impose des contraintes. Elle définit qui décide quoi, comment les priorités sont arbitrées, quand on dit non à une nouvelle demande, comment on mesure l’avancement. Ces contraintes sont précisément ce qui la rend efficace — et ce qui la rend inconfortable pour les organisations qui préfèrent l’ambiguïté à la clarté.
L’absence de méthode réelle est souvent le symptôme d’une organisation où personne n’a vraiment l’autorité — ou le courage — d’imposer ces contraintes. Où le Product Owner ne peut pas dire non aux demandes du CODIR. Où le périmètre d’un sprint peut être modifié à tout moment par le manager d’une direction.
Comment reconnaître une organisation qui a vraiment une méthode
Quelques questions qui font la différence entre le vernis et la substance :
Comment priorisez-vous votre backlog ?
Une vraie réponse nomme un processus, des critères, une responsabilité. Une fausse réponse parle de discussions collectives et de consensus.
Que se passe-t-il quand une urgence arrive en cours de sprint ?
Une vraie réponse décrit comment l’urgence est évaluée, comment elle est intégrée ou reportée, et qui décide. Une fausse réponse dit on s’adapte.
Comment mesurez-vous la vélocité de vos équipes ?
Une vraie réponse cite des métriques et explique comment elles sont utilisées pour améliorer les estimations. Une fausse réponse dit que les équipes se connaissent bien et savent ce qu’elles peuvent faire.
Qu’avez-vous changé suite à votre dernière rétrospective ?
Une vraie réponse cite un changement précis. Une fausse réponse évoque une discussion intéressante.
Ce qu’il faut vraiment faire
La bonne nouvelle — parce qu’il y en a une — est que la solution n’est pas de chercher la méthode parfaite. Il n’en existe pas. Scrum, Kanban, Shape Up, ou n’importe quelle autre approche n’est pas une recette universelle qui fonctionnera dans tous les contextes.
La vraie question n’est pas quelle méthode adopter ? C’est quels problèmes concrets essaie-t-on de résoudre, et quelles pratiques spécifiques vont aider à les résoudre ?
Une organisation dont le problème principal est la surcharge des équipes a besoin de limites de WIP et de priorisation rigoureuse. Une organisation dont le problème est le décalage entre ce qu’on construit et ce dont les utilisateurs ont besoin a besoin de cycles courts et de feedback utilisateur régulier. Ces réponses peuvent emprunter à différents frameworks — mais elles partent du problème, pas du nom.
Et elles nécessitent un leadership IT capable de tenir la discipline dans le temps. Parce que les méthodes, même les meilleures, ne s’appliquent pas seules. Elles demandent du courage managérial : le courage de dire non aux demandes hors-périmètre, de défendre l’amélioration continue face à l’urgence permanente, et d’expliquer au CODIR pourquoi livrer moins mais mieux est plus intelligent que livrer vite et mal.
Ce qu’il faut retenir
Le problème des méthodologies projet dans les organisations IT n’est pas un problème de choix de framework. C’est un problème de sincérité.
Soit on applique vraiment une méthode — avec ses contraintes, ses rituels, sa discipline — et on en tire les bénéfices. Soit on porte une étiquette pour avoir l’air moderne, et on continue de travailler dans le désordre avec un vocabulaire plus sophistiqué.
La distinction ne se voit pas dans les slides de présentation ni dans les titres des fiches de poste. Elle se voit dans ce qui se passe quand une urgence arrive, quand une demande doit être refusée, quand une rétrospective identifie un problème qu’il serait inconfortable de résoudre.
Chez Kalyptus, nous rencontrons régulièrement cette réalité dans nos missions de recrutement de CTO et de VP Engineering — des organisations qui cherchent un profil capable de structurer les pratiques de développement en découvrant, en creusant, que la vraie traduction est : remettre de la méthode là où il n’y a plus que des termes. C’est l’un des mandats les plus fréquents — et l’un des moins souvent nommés clairement dans les fiches de poste.
Agile, SAFe, Scrum, Shape Up, LeSS : quand le nom de la méthode devient plus important que la méthode elle-même — et comment reconnaître une organisation qui n’en a tout simplement pas.
Il existe un test simple pour savoir si une organisation applique vraiment une méthodologie projet ou si elle en porte simplement le t-shirt.
Posez la question suivante à cinq personnes différentes dans l’équipe IT : comment vous organisez-vous pour livrer un projet ?
Si vous obtenez cinq réponses cohérentes, décrivant les mêmes processus, les mêmes rituels, les mêmes responsabilités — avec peut-être des nuances sur les détails — vous avez affaire à une organisation qui a une méthode réelle.
Si vous obtenez cinq réponses différentes, dont certaines mentionnent Agile, certaines Scrum, certaines on s’adapte selon les projets, et une qui évoque vaguement des sprints sans savoir vraiment à quoi ça sert — vous avez affaire à une organisation qui a une étiquette. Pas une méthode.
La différence entre les deux est plus répandue qu’on ne le croit. Et elle a des conséquences très concrètes sur les projets, les équipes et les budgets.
Le marché des étiquettes méthodologiques : une inflation incontrôlée
Depuis que l’Agile Manifesto a été signé en 2001 par dix-sept développeurs dans un chalet d’Utah, le terme agile est devenu l’un des mots les plus utilisés — et les plus vidés de sens — de l’écosystème IT.
Il a d’abord désigné une philosophie de développement logiciel fondée sur quatre valeurs et douze principes. Puis il est devenu un framework (Scrum), puis plusieurs frameworks (Kanban, XP, SAFe, LeSS, Shape Up, Nexus, DAD — la liste continue de s’allonger). Puis il est devenu un adjectif applicable à n’importe quoi : une réunion agile, une organisation agile, une stratégie agile, un budget agile. Puis il est devenu une valeur d’entreprise inscrite dans les rapports annuels, entre innovation et excellence opérationnelle.
À ce stade, agile ne veut plus dire grand-chose. Et c’est précisément le problème. Chaque fois qu’un terme devient suffisamment populaire pour entrer dans le vocabulaire managérial généraliste, il se vide de sa substance opérationnelle. Il reste le mot, sans le contenu. L’étiquette, sans la méthode.
Taxonomie des fausses méthodologies — un guide de terrain
Il existe plusieurs variétés de méthodo-fantômes, chacune avec ses caractéristiques propres. Les reconnaître permet de ne pas se laisser impressionner par le vocabulaire.
L’Agile de façade
C’est la variété la plus répandue. Elle se caractérise par la présence de tous les artefacts visibles de Scrum — des sprints de deux semaines, un backlog, des daily stand-ups, un Scrum Master et un Product Owner avec les titres sur la carte de visite — et l’absence de ce qui fait fonctionner la méthode dans la réalité.
Les sprints existent, mais leur périmètre est modifié en cours de route à chaque demande de la direction. Le backlog existe, mais personne ne l’a vraiment priorisé depuis trois mois. Les daily stand-ups existent, mais ils durent quarante-cinq minutes et ressemblent davantage à des réunions de reporting qu’à des synchronisations d’équipe. Le Product Owner existe, mais il n’a pas réellement l’autorité pour prendre des décisions sur le produit.
Le résultat : une organisation qui a tous les coûts de l’Agile (les rituels, la réorganisation en squads, les outils de suivi) et aucun de ses bénéfices (la réactivité, l’amélioration continue, la livraison de valeur régulière).
Le SAFe qui cache un cycle en V
SAFe — Scaled Agile Framework — est à l’Agile ce que le SUV est à la voiture de sport : ça en emprunte l’esthétique, mais la conduite est fondamentalement différente. SAFe est une réponse au problème réel de mise à l’échelle de l’Agile dans les grandes organisations, avec ses PI Planning, ses Agile Release Trains et sa gouvernance multi-niveaux.
Dans beaucoup d’organisations, SAFe est devenu le véhicule présentable pour maintenir un cycle en V classique sous une terminologie agile. Le PI Planning ressemble à une messe trimestrielle où les équipes décrivent ce qu’elles vont faire pendant les trois prochains mois. Ce qui n’est pas très différent d’un planning classique, si ce n’est que c’est nettement plus long et qu’il y a des post-its.
Le Kanban sans limites
Le Kanban est une méthode de gestion du flux fondée sur un principe simple et puissant : limiter le travail en cours (WIP) pour améliorer le débit et identifier les goulots d’étranglement. Dans sa forme pure, c’est un outil remarquablement efficace.
Dans sa version dégradée — la plus courante — le Kanban est un tableau avec des colonnes et des cartes qui s’accumulent dans la colonne En cours sans jamais vraiment se terminer. Les limites de WIP, qui sont le coeur de la méthode, ne sont pas appliquées parce que personne ne veut dire non à une nouvelle tâche. Résultat : le tableau visualise le chaos sans le réduire. C’est un thermomètre qu’on a confondu avec un traitement.
Le Shape Up mal digéré
Shape Up est la méthode développée par Basecamp qui a rencontré un succès certain dans les entreprises produit ces dernières années. Elle propose des cycles de six semaines, des équipes autonomes, et une discipline rigoureuse sur la définition des problèmes à résoudre avant de commencer à les résoudre.
Sa version mal digérée ressemble à ceci : on prend les six semaines (parce que c’est plus long que les sprints de deux semaines, ce qui arrange tout le monde), on les appelle Shape Up cycles, on abandonne les daily stand-ups (parce que Shape Up n’en préconise pas, et ça arrange les managers qui les trouvaient chronophages), et on continue de travailler exactement comme avant — juste avec des cycles plus longs et sans réunions de synchronisation. Le résultat est généralement une organisation moins coordonnée, pas plus autonome.
La méthodo sur mesure qui est en réalité l’absence de méthodo
La plus difficile à détecter, parce qu’elle se présente comme une sophistication. Nous avons développé notre propre approche, adaptée à notre contexte. Nous sommes pragmatiques, nous prenons ce qui fonctionne dans chaque méthode. Nous n’appliquons pas un framework dogmatiquement.
Ces phrases peuvent décrire une organisation mature qui a effectivement internalisé les principes de plusieurs méthodes et les applique avec discernement. Elles peuvent aussi décrire une organisation qui n’a jamais vraiment appliqué aucune méthode, qui change d’approche à chaque projet selon la préférence du chef de projet, et qui appelle ça de l’adaptabilité.
Pour distinguer les deux : demandez comment les décisions de priorisation sont prises. Une organisation qui a une vraie méthode, même sur mesure, a une réponse précise. Une organisation sans méthode réelle a une réponse vague sur le consensus et la discussion.
Pourquoi les étiquettes se substituent aux méthodes
Ce phénomène de rebranding méthodologique n’est pas le fruit du hasard ou de la mauvaise foi. Il a des causes structurelles qu’il faut comprendre pour ne pas simplement les condamner.
La pression de la modernité
Toute organisation IT qui se respecte doit aujourd’hui se déclarer agile. C’est une exigence implicite des recrutements, des appels d’offres, et des discours de direction. Cette pression crée une incitation puissante à adopter les termes sans nécessairement adopter les pratiques.
La résistance organisationnelle au vrai changement
Appliquer vraiment l’Agile dans une grande organisation nécessite de changer des choses que beaucoup de personnes ne veulent pas changer. Donner de l’autonomie réelle aux équipes implique que les managers intermédiaires lâchent du contrôle. Prioriser rigoureusement le backlog implique de dire non à des demandes. Livrer par petits incréments testables implique d’accepter une phase d’imperfection visible. Ces changements sont difficiles politiquement. Adopter le vocabulaire sans les pratiques permet d’éviter ces frictions.
Le marché des consultants et des certifications
Il existe un écosystème entier d’organisations qui vivent de la vente de formations, de certifications et de missions de conseil autour des frameworks agiles. Cet écosystème a un intérêt structurel à la multiplication et à la complexification des frameworks. Plus il y a de certifications à passer, de niveaux à atteindre, de rôles à créer, plus le marché est grand. SAFe compte aujourd’hui plus de vingt rôles certifiables. C’est autant de formations à vendre.
La confusion entre adoption et transformation
Beaucoup d’organisations confondent l’adoption d’un vocabulaire ou d’outils avec la transformation culturelle que la méthode est censée produire. On installe Jira et on pense être agile. On forme les équipes à Scrum et on pense avoir changé la façon dont les décisions sont prises. L’outil ou le framework est nécessaire mais pas suffisant — et cette différence est rarement expliquée clairement par ceux qui ont intérêt à vendre l’adoption.
Ce que révèle l’absence de méthode réelle
Une organisation sans méthode projet réelle n’est pas seulement moins efficace dans ses livraisons. Elle révèle quelque chose de plus profond sur son rapport à la gouvernance, à la responsabilité et au leadership.
Une méthode réelle impose des contraintes. Elle définit qui décide quoi, comment les priorités sont arbitrées, quand on dit non à une nouvelle demande, comment on mesure l’avancement. Ces contraintes sont précisément ce qui la rend efficace — et ce qui la rend inconfortable pour les organisations qui préfèrent l’ambiguïté à la clarté.
L’absence de méthode réelle est souvent le symptôme d’une organisation où personne n’a vraiment l’autorité — ou le courage — d’imposer ces contraintes. Où le Product Owner ne peut pas dire non aux demandes du CODIR. Où le périmètre d’un sprint peut être modifié à tout moment par le manager d’une direction.
Comment reconnaître une organisation qui a vraiment une méthode
Quelques questions qui font la différence entre le vernis et la substance :
Comment priorisez-vous votre backlog ?
Une vraie réponse nomme un processus, des critères, une responsabilité. Une fausse réponse parle de discussions collectives et de consensus.
Que se passe-t-il quand une urgence arrive en cours de sprint ?
Une vraie réponse décrit comment l’urgence est évaluée, comment elle est intégrée ou reportée, et qui décide. Une fausse réponse dit on s’adapte.
Comment mesurez-vous la vélocité de vos équipes ?
Une vraie réponse cite des métriques et explique comment elles sont utilisées pour améliorer les estimations. Une fausse réponse dit que les équipes se connaissent bien et savent ce qu’elles peuvent faire.
Qu’avez-vous changé suite à votre dernière rétrospective ?
Une vraie réponse cite un changement précis. Une fausse réponse évoque une discussion intéressante.
Ce qu’il faut vraiment faire
La bonne nouvelle — parce qu’il y en a une — est que la solution n’est pas de chercher la méthode parfaite. Il n’en existe pas. Scrum, Kanban, Shape Up, ou n’importe quelle autre approche n’est pas une recette universelle qui fonctionnera dans tous les contextes.
La vraie question n’est pas quelle méthode adopter ? C’est quels problèmes concrets essaie-t-on de résoudre, et quelles pratiques spécifiques vont aider à les résoudre ?
Une organisation dont le problème principal est la surcharge des équipes a besoin de limites de WIP et de priorisation rigoureuse. Une organisation dont le problème est le décalage entre ce qu’on construit et ce dont les utilisateurs ont besoin a besoin de cycles courts et de feedback utilisateur régulier. Ces réponses peuvent emprunter à différents frameworks — mais elles partent du problème, pas du nom.
Et elles nécessitent un leadership IT capable de tenir la discipline dans le temps. Parce que les méthodes, même les meilleures, ne s’appliquent pas seules. Elles demandent du courage managérial : le courage de dire non aux demandes hors-périmètre, de défendre l’amélioration continue face à l’urgence permanente, et d’expliquer au CODIR pourquoi livrer moins mais mieux est plus intelligent que livrer vite et mal.
Ce qu’il faut retenir
Le problème des méthodologies projet dans les organisations IT n’est pas un problème de choix de framework. C’est un problème de sincérité.
Soit on applique vraiment une méthode — avec ses contraintes, ses rituels, sa discipline — et on en tire les bénéfices. Soit on porte une étiquette pour avoir l’air moderne, et on continue de travailler dans le désordre avec un vocabulaire plus sophistiqué.
La distinction ne se voit pas dans les slides de présentation ni dans les titres des fiches de poste. Elle se voit dans ce qui se passe quand une urgence arrive, quand une demande doit être refusée, quand une rétrospective identifie un problème qu’il serait inconfortable de résoudre.
Chez Kalyptus, nous rencontrons régulièrement cette réalité dans nos missions de recrutement de CTO et de VP Engineering — des organisations qui cherchent un profil capable de structurer les pratiques de développement en découvrant, en creusant, que la vraie traduction est : remettre de la méthode là où il n’y a plus que des termes. C’est l’un des mandats les plus fréquents — et l’un des moins souvent nommés clairement dans les fiches de poste.