NEWNouveau : Rapport de positionnement B2B SaaS French Tech 2026  Lire le rapport →

Quelques clés pour définir des objectifs

9 min read

Cet article a été traduit automatiquement depuis sa version originale.

Pourquoi ne pas lire cet article plus loin

Je me suis demandé un moment si j’allais intituler cet article “Oubliez les objectifs”. Pourquoi ? Essentiellement parce que, comme vous l’avez peut-être remarqué si vous avez lu certains de mes articles passés, je suis plutôt contre les dogmes. Et aujourd’hui, du moins dans l’industrie du logiciel, la plupart des discussions que j’ai avec des gens sur les “objectifs” incluent le terme “OKR”.

Si vous cherchez un guide étape par étape pour définir des OKRs, ne lisez pas plus loin. Si vous êtes intéressé par les pièges que j’ai vus et mes conseils pour les éviter, je suis heureux de les partager ci-dessous.

Note : je n’ai jamais vu des OKRs correctement définis, ni produisant les résultats attendus. C’est comme le modèle Spotify : il y a la théorie, et puis il y a les humains. Les humains n’ont tout simplement pas l’Esprit de la Ruche. Laissez ça mijoter.

Répétons-le. Les humains n’ont pas l’Esprit de la Ruche. Pour notre gloire et notre déclin.

Oh, et aussi : ce sujet m’a beaucoup inspiré. Il y a beaucoup de mots ci-dessous. Mais j’ai essayé de le résumer avec un aide-mémoire à la fin. N’hésitez pas à y sauter directement.

Les OKRs et tout ça

Merci beaucoup de lire jusqu’à ce point, surtout si vous n’avez toujours aucune idée de ce qu’est un OKR. Par souci de transparence, même si j’essaie de travailler avec et d’en discuter depuis des années, ça me prend toujours une seconde. Objectifs et Résultats Clés. Voilà.

OK, je l’avoue. Avant de commencer à écrire ceci, j’ai à nouveau recherché sur Google. Le premier résultat était un guide Atlassian. Wow, ça escalade vite. S’il vous plaît, ne cliquez pas sur le lien. Laissez-moi vous copier quelques extraits :

Un OKR est une stratégie de management populaire qui définit des objectifs et suit les résultats. Il aide à créer l’alignement et l’engagement autour d’objectifs mesurables.

Ça m’a perdu au 5e mot. Oui, “populaire”. Tout ce que je sais, c’est que la plupart des choses “populaires” dans le monde tech sont souvent profondément mal interprétées et mal implémentées. Et qu’après un moment, on revient en arrière en pensant : “Hmm, ce n’était finalement pas une si bonne idée”. Nous sommes tous très bons pour suivre aveuglément des “thought leaders” et essayer de copier ce qu’ils font, même dans des situations très différentes qui ne s’appliquent pas. Si vous l’avez raté : Amazon, l’une des sources des tendances microservices et serverless, a expliqué comment ils sont revenus en arrière dans une situation particulière. Pardon pour la digression, continuons à lire.

“Stratégie de management qui définit des objectifs et suit les résultats”. Ça semble sage. C’est à peu près la même chose que SMART, alors.

Laissons le jargon de côté. Tout ça a en commun : il s’agit d’obtenir de la clarté sur ce que vous voulez accomplir et d’avoir des moyens non biaisés de déterminer les accomplissements.

Viser une cible en mouvement

Je vous ai dit que j’ai travaillé la plupart de ma carrière comme Product Manager ? Qu’est-ce qu’on demande le plus souvent à un Product Manager ? Une Roadmap ! Est-ce que quelqu’un a jamais gravé une roadmap dans la pierre et que tout s’est passé selon le plan ? Jamais. Un estimable collègue à moi l’a formulé :

Une roadmap est un animal vivant. Elle grandit, elle change. Et c’est très bien.

Une Roadmap est probablement la façon la plus extensive d’écrire un ensemble d’objectifs que j’ai expérimentée. Elle s’étend sur plusieurs semaines ou mois (non, ne demandez pas des années) ; elle est limitée dans le temps. Elle est spécifique. Elle devrait être réalisable. Il y a un moyen non biaisé d’évaluer si les choses sont livrées. Elle est décomposée en plusieurs livrables. Elle impacte plusieurs personnes ou équipes.

Bien que faire une prédiction sur le moment où une fonctionnalité donnée sera livrée soit plus ou moins comme tirer dans le noir, toutes sortes d’obstacles font qu’on tire simultanément dans le noir sur une cible en mouvement.

Les OKRs ou tout type d’objectifs devraient d’abord être définis au niveau de l’entreprise. Comment ose-t-on faire ça en sachant qu’on ne les atteindra pas ? Dans l’industrie du logiciel, beaucoup tourne autour du produit et de sa roadmap.

Devrait-on même essayer ? J’essaierai de donner quelques réponses. Spoiler : oui, nous devrions. Une cible en mouvement requiert une visée en mouvement. Un environnement changeant requiert des objectifs changeants.

Responsabilité et imputabilité

Arrêtons-nous un instant pour clarifier la Responsabilité et l’Imputabilité (lecture recommandée : RACI). Le dernier paragraphe met en effet un poids assez lourd sur les épaules du Product Manager, non ? S’ils échouent à prédire leur roadmap, les ingénieurs n’atteindront pas leurs objectifs. Les ventes ne vendront pas assez. Le MRR et l’ARPA ne seront pas aussi beaux. On s’en prend aux PMs.

Attendez quoi ? Je sais que les humains n’ont pas l’Esprit de la Ruche, mais les PMs devraient-ils être mis à l’index collectivement ? Les PMs sont responsables de l’écriture de la roadmap, mais ne peuvent pas en être tenus imputables. Définir ce qui est dans la roadmap est un effort d’équipe. Essayer de réaliser la roadmap est un effort d’équipe. Les obstacles sont un fardeau collectif.

Clairement l’un des plus grands pièges que j’ai vus. Les objectifs rendent les gens imputables, même quand ils ne sont pas définis au niveau d’une personne. Soit parce que quand ils ne sont pas atteints, quelqu’un essaiera de blâmer la personne qui en était responsable ou imputable (confondant les deux, la plupart du temps), soit parce que la personne se blâmera elle-même de toute façon. Vous ne pouvez être tenu imputable que des choses sur lesquelles vous avez le contrôle.

Vous me direz : “Eh bien oui, c’est précisément le but des objectifs”. Je suis tellement désolé que l’ancien paradigme Commandement & Contrôle ait encore autant d’impact dans le monde d’aujourd’hui. Permettez-moi d’ouvrir cette porte : échouer, c’est bien. Vous pouvez échouer. Les autres peuvent échouer. Ce qui compte, c’est ce que vous faites de cet échec. En fait, vous pouvez même arrêter de l’appeler “échec” et réaliser que c’est juste un objectif manqué.

Alors pourquoi définir des objectifs, après tout ?

Parce qu’on apprend ! J’essaie d’éviter les métaphores, alors pardonnez-moi pour celle-ci : quand vous vous garez en créneau dans un espace étroit, vous avez généralement besoin de plusieurs tentatives. Vous ne vous arrêterez pas au premier essai raté. Vous regardez dans les rétroviseurs et vous ajustez. Et vous devriez faire encore plus si l’espace se déplaçait pendant que vous vous gariez.

J’ai mentionné que définir un objectif est une tâche complexe. Et un critère clé est de le rendre “réalisable”.

Toujours pas croyant aux dogmes, j’aime l’idée de “l’appétit” dans la méthode Shape Up, car elle équilibre l’ambition et le besoin d’atteindre un objectif spécifique. De quelle quantité avez-vous faim ? Savez-vous avec certitude que telle ou telle quantité est suffisante ? Et quand c’est suffisant pour nourrir votre corps, en prendrez-vous encore un peu, parce que vous aimez ça et que vous pouvez ?

Faites un pari éclairé ! Ça donne une direction. Ça apporte de la clarté.

Ensuite, suivez la métrique des objectifs en continu. N’attendez pas d’être dos au mur pour réaliser que le mur est trop haut. Si vous avez la chance d’ajuster soit vos efforts soit votre objectif, faites-le.

Et quand vous manquez l’objectif, ce qui arrivera, il n’y a pas de blâme. Il y a des leçons à tirer. N’étiez-vous pas assez affamé ? Des obstacles ont-ils sérieusement impacté la livraison ? Peuvent-ils être évités la prochaine fois, ou devriez-vous simplement savoir que vous avez besoin d’une marge de sécurité en cas de récurrence ?

Je comprends vraiment la réticence des ingénieurs à dire “combien de temps quelque chose prendra à développer”. Appelez ça comme vous voulez : heures-homme, jours, points de complexité. N’importe quel type d’engagement. Parce qu’ils ont toujours été les premiers à être blâmés pour ne pas avoir livré selon leurs estimations.

Le meilleur succès que j’ai expérimenté est en définissant des métriques abstraites qui donnaient une idée de la quantité de travail qu’une tâche représenterait, par rapport aux autres. Les valeurs absolues ne peuvent tout simplement pas fonctionner. Les valeurs relatives ont cette chance :

  • elles peuvent fluctuer, et donc s’ajuster dans le temps à une équipe ou un environnement donné. Quelque chose de “difficile” pour quelqu’un peut être “facile” pour d’autres dans des contextes différents ;
  • en faisant un pari éclairé pour la métrique d’une tâche donnée, on peut faire un pari mieux éclairé pour une tâche similaire la prochaine fois. Retenez bien le mot “pari”. Pas “engagement”. Pas “estimation”. Rien d’absolu.

Permettez-moi de succomber à celle-ci aussi (désolé) :

Visez la lune. Même si vous la manquez, vous atterrirez parmi les étoiles.

  • Norman Vincent Peale

Honnêtement : visez ce que vous voulez. Ensuite, assurez-vous de savoir où vous avez atterri et où vous voulez aller ensuite.

Incitations financières

Tout ça c’est bien beau, mais vous êtes là pour gérer une entreprise. Les gens devraient obtenir un bonus s’ils vous aident à atteindre le succès.

Eh bien, je suis encore hésitant à répondre ça pour les postes commerciaux. Mais dans d’autres situations, laissez-moi vous dire : non.

Ce qui m’a vraiment poussé à écrire ce (très) long article est une discussion que j’avais sur un canal Slack de product management, sur les incitations financières liées aux objectifs pour les PMs. Ce fil comprend d’innombrables anecdotes de personnes qui ont craqué, renoncé à des objectifs qu’elles ne pouvaient pas atteindre, triché avec le système, eu des comportements toxiques envers leurs pairs, ou tout simplement s’en fichaient complètement.

Autant vous devriez récompenser et reconnaître quelqu’un pour ses réalisations exceptionnelles, gardez à l’esprit :

  • Ne pas récompenser les autres ne les motivera pas beaucoup. C’est les pénaliser.
  • Sauf si vous avez des objectifs définis à la perfection (malgré tout ce que j’ai écrit ci-dessus), il y a de bonnes chances que leur évaluation d’accomplissement soit biaisée. Quel biais avez-vous introduit, et pouvez-vous être équitable envers les autres ?
  • Les gens ne peuvent pas suspendre leur vie à une vaste série d’événements incertains et de la bonne volonté des autres. Leur salaire devrait être suffisant pour qu’ils n’aient tout simplement pas besoin de s’inquiéter d’obtenir un bonus. Perdant ainsi le sens de l’“incitation”.
  • Ne brandissez pas une carotte que vous ne possédez pas. L’argent n’est pas le vôtre. Si votre patron, pour de bonnes ou mauvaises raisons, décide que vous ne pouvez pas le donner, VOUS aurez trahi votre équipe. Parlons de responsabilité…

Aide-mémoire

En bref : vous avez besoin d’objectifs. Mais seulement si vous les définissez judicieusement.

  • Spécifiques, Mesurables, Atteignables, Pertinents, Temporellement définis.
  • Faites un pari éclairé.
  • Revoyez et adaptez constamment vos objectifs.
  • Les valeurs absolues font souvent de mauvais objectifs. Cherchez des valeurs relatives (% d’augmentation/diminution).
  • Les humains n’ont pas l’Esprit de la Ruche. Ne leur demandez pas de changer. C’est bien.
  • Vous ne pouvez être tenu imputable que des choses sur lesquelles vous avez le contrôle.
  • Il ne doit pas s’agir de pénaliser.
  • Il s’agit de donner une direction.
  • Manquer, c’est bien.
  • Il doit s’agir d’apprendre.
  • Abstenez-vous de lier objectifs et incitations financières.

Image de une par Christian Kaden

Partager :

Articles liés

Vos commerciaux ne savent pas ce qu'ils vendent
Christophe Dujarric Product Management

Vos commerciaux ne savent pas ce qu'ils vendent

Dans un article précédent, j’ai écrit que votre équipe commerciale ne sait pas ce qu’elle vend. Par là, j’entends qu’ils ne sont…

Voir plus →
Le produit, c'est l'organisation
Christophe Dujarric Product Management

Le produit, c'est l'organisation

Le produit, c’est le business. Le problème utilisateur est l’essence du produit. Laissez-moi reformuler : le produit, c’est…

Voir plus →
Pourquoi les partenariats stratégiques et les marketplaces échouent
Christophe Dujarric Product Management

Pourquoi les partenariats stratégiques et les marketplaces échouent

Les partenariats stratégiques peuvent parfois ressembler à un Eldorado. Mais la plupart du temps, vous creusez jusqu’à vous user les ongles pour des…

Voir plus →