Modèle de théorie du changement : le cadre associatif qui manque à vos OKRs

Demandez à un responsable de programme dans une association à but non lucratif de défendre une demande de financement, et en moins de cinq minutes, il vous présentera un diagramme : intrants, activités, extrants, résultats, impact, chaque case menant logiquement à la suivante. Demandez à un product manager de justifier pourquoi un élément de la feuille de route est censé faire bouger un chiffre de revenu, et vous obtiendrez généralement un haussement d'épaules, une diapositive avec un graphique en crosse de hockey, ou « parce que notre concurrent a sorti quelque chose de similaire ».

Ce diagramme que le responsable de programme vous a montré porte un nom. C'est un modèle de théorie du changement, l'un des outils de planification les plus rigoureux qui existent, et presque aucune équipe business ne l'utilise. Pas parce qu'il ne s'applique pas. Parce que presque personne en dehors du développement international, de la santé publique et du financement de l'éducation n'y a jamais été exposé.

C'est dommage. La logique sous-jacente à un modèle de théorie du changement, une chaîne explicite de type si-alors reliant ce que vous faites à ce que cela change, est précisément ce qui manque à la plupart des OKRs, feuilles de route et plans stratégiques. Les équipes s'engagent sans cesse dans des initiatives sans jamais écrire pourquoi elles pensent que cette initiative fera bouger la métrique qu'elles visent. Un modèle de théorie du changement oblige à coucher cette conviction sur le papier, publiquement, là où quelqu'un peut réellement la contester.

Voici ce qu'est réellement un modèle de théorie du changement, pourquoi la version associative ne survit pas au contact d'une entreprise, et comment en mener un sans qu'il ne devienne une diapositive de plus que personne ne rouvre.

Ce qu'est réellement un modèle de théorie du changement

Un modèle de théorie du changement cartographie la chaîne causale entre ce que fait une organisation et le changement qu'elle cherche à créer, généralement en cinq étapes :

• Intrants : les ressources que vous mobilisez (personnes, budget, temps)
• Activités : ce que vous faites concrètement avec ces ressources
• Extrants : le résultat direct et mesurable de l'activité (un programme livré, une fonctionnalité déployée)
• Résultats : le comportement ou la situation qui change grâce à cet extrant
• Impact : l'objectif à plus long terme que tout cela est censé servir

Ce qui le distingue d'un simple plan de projet, ce sont les flèches, pas les cases. Entre chaque étape se trouve une hypothèse : si nous menons cette activité, alors cet extrant suivra, pour cette raison précise. Un modèle de théorie du changement vous demande de nommer cette raison à voix haute, au lieu de supposer que tout le monde est déjà d'accord.

C'est aussi là que les gens le confondent avec un modèle logique. Un modèle logique cartographie les cinq mêmes cases et documente surtout ce qui est censé se produire. Un modèle de théorie du changement va plus loin et documente pourquoi vous pensez que cela va se produire, y compris les hypothèses et les risques susceptibles de rompre la chaîne en cours de route. En pratique, la plupart des gens emploient les deux termes de façon interchangeable, mais pour être précis : un modèle logique est la carte, et une théorie du changement est la carte plus le raisonnement qui la sous-tend.

Pourquoi la version associative ne survit pas au contact d'une entreprise

Les associations construisent des modèles de théorie du changement pour satisfaire leurs financeurs, pas pour piloter l'organisation au quotidien. Le modèle est construit une fois, en amont d'une demande de subvention, reçoit un joli traitement graphique de la part de quelqu'un à l'aise avec un tableau blanc, puis finit dans un dossier jusqu'à ce que le cycle de financement suivant oblige quelqu'un à le dépoussiérer.

Les équipes business qui empruntent ce cadre ont tendance à commettre exactement la même erreur. Il apparaît sous forme de diapositive lors d'un séminaire stratégique, tout le monde hoche la tête, et plus personne n'y fait référence jusqu'à ce que quelqu'un demande « attendez, pourquoi fait-on ce projet ? » six mois plus tard, et que personne ne se souvienne vraiment du raisonnement initial. Le document n'a jamais été faux. Il n'a simplement jamais été conçu pour servir plus d'une fois.

Comment cela se traduit dans les OKRs

Si vous utilisez déjà les OKRs, vous disposez en fait déjà des deux tiers d'un modèle de théorie du changement, sans la couche de raisonnement. L'Objective, c'est l'impact. Les Key Results, ce sont les résultats. Les initiatives sous chaque Key Result sont les activités et les extrants.

(voir aussi : Extrants vs résultats)

La partie que presque tout le monde saute, c'est l'hypothèse qui relie une initiative à un Key Result : le « parce que » qui explique pourquoi ce travail précis devrait faire bouger ce chiffre précis. Si vous la sautez, les OKRs se transforment en simple liste de tâches avec un tableau de bord greffé dessus. Si vous l'incluez, les OKRs deviennent ce qu'ils sont censés être, une couche de traduction entre la stratégie et l'exécution, ce qui est exactement le rôle que nous avons décrit dans l'exécution de la stratégie. Un modèle de théorie du changement n'est qu'une façon plus rigoureuse d'écrire cette traduction avant d'y engager de vraies ressources.

Une méthode en quatre étapes pour en mener un sans qu'il ne devienne obsolète

1. Écrivez la chaîne pour une initiative à la fois, pas pour toute l'entreprise. Un modèle de théorie du changement à l'échelle de l'entreprise est trop abstrait pour que quiconque puisse le contester. Un modèle au niveau d'une initiative, « si nous livrons X, alors Y, parce que Z », est suffisamment concret pour que quelqu'un puisse réellement ne pas être d'accord.
2. Nommez l'hypothèse à chaque flèche, pas seulement les cases. « Nous allons créer une checklist d'onboarding » est une activité. « Parce qu'un time-to-value plus rapide cause une baisse du churn, et ne fait pas que corréler avec elle » est l'hypothèse qui fait tout le travail.
3. Rattachez-la à une cadence, pas à un document de planification annuel. Un modèle de théorie du changement qui n'est rouvert qu'une fois par an est un document de subvention associatif déguisé en costume d'entreprise. Associez-le aux mêmes check-ins que vous menez déjà pour vos OKRs, afin que l'hypothèse soit testée face à de vrais chiffres plutôt que simplement gardée en mémoire avec nostalgie.
4. Revisitez et élaguez les maillons rompus. Quand un résultat n'évolue pas comme la chaîne le prédisait, la solution n'est généralement pas une nouvelle tactique greffée sur la même hypothèse. C'est d'admettre que l'hypothèse était fausse et de réécrire ce maillon avant que le trimestre suivant ne répète la même erreur.

Un exemple concret

Une équipe SaaS B2B de 40 personnes pense que son problème de churn à 90 jours est en réalité un problème de time-to-value. Correctement rédigé, leur modèle de théorie du changement ressemble à ceci :

• Intrants : deux ingénieurs, un designer, trois semaines
• Activités : créer une checklist d'onboarding in-app couvrant les cinq étapes de configuration corrélées à la rétention des comptes
• Extrants : pourcentage de nouveaux comptes qui terminent la checklist au cours de la première semaine
• Résultats : le time-to-first-value médian passe de 12 à 4 jours ; le churn à 90 jours baisse parmi les comptes ayant terminé la checklist
• Impact : la net revenue retention s'améliore pour cette cohorte

L'hypothèse qui se trouve sur la flèche entre l'extrant et le résultat est celle qui mérite d'être débattue avant que quiconque n'écrive une ligne de code : terminer la checklist plus vite cause-t-il réellement une baisse du churn, ou les comptes les plus susceptibles de la terminer rapidement étaient-ils déjà, de toute façon, les plus susceptibles de rester ? C'est une question testable, pas rhétorique. Un check-in hebdomadaire sur l'indicateur avancé, le taux de complétion de la checklist, indique à l'équipe en moins d'un mois si la théorie tient, plutôt que de découvrir au prochain QBR qu'un trimestre entier de temps d'ingénierie a poursuivi une corrélation au lieu d'une cause.

Erreurs courantes

• Partir de la métrique d'impact et remonter vers des activités qui semblent plausibles, plutôt que partir de ce que l'équipe peut réellement contrôler et avancer dans le bon sens.
• Sauter l'hypothèse et traiter une histoire qui sonne plausible comme s'il s'agissait du plan lui-même.
• Le traiter comme un document plutôt que comme une hypothèse. Classé au lieu d'être testé, révisé, ou parfois abandonné.
• Le confondre avec une roadmap. Une roadmap dit ce que vous construisez et quand. Un modèle de théorie du changement dit pourquoi vous pensez que cela compte, ce qu'une roadmap omet généralement entièrement.

La place de Tability

Rien de tout cela ne nécessite un nouveau logiciel. Cela nécessite d'écrire l'hypothèse quelque part où tout le monde peut la voir, et de la vérifier selon une cadence plutôt qu'une fois par an. Des outils comme Tability sont conçus exactement pour cela : un endroit où rattacher une initiative au Key Result qu'elle est censée faire bouger, avec un historique de check-ins qui montre si l'hypothèse sous-jacente tient bon ou s'effondre discrètement. C'est la même couche opérationnelle que celle que nous avons décrite dans StratOps et le framework OKR.

Si vous cherchez à faire débattre votre équipe sur les hypothèses avant d'y engager tout un trimestre de temps d'ingénierie, ou si vous construisez la fonction StratOps qui rend ce type de réflexion systématique, inscrivez-vous gratuitement à Tability ou réservez 30 minutes avec nous et nous vous aiderons à déterminer à quoi cela ressemble pour votre équipe. Avec ou sans Tability, écrire le « parce que » vaut la peine dans tous les cas.