Équipe Ops ou Performance : comment structurer la fonction qui fait vraiment tourner la machine

1. Ops ou Performance : pourquoi le nom de l'équipe révèle son ambition réelle

C'est la première chose qui m'a frappé dans cet échange. Jean-Baptiste ne commence pas par parler de méthode. Il commence par parler de sens.

Pour lui, nommer une équipe "Sales Ops", "RevOps" ou "Business Ops" crée par nature un silo. Le nom dit à qui l'équipe appartient, pas ce qu'elle fait. Les managers des autres équipes ne comprennent pas vraiment à quoi cette équipe sert, et l'équipe elle-même finit par limiter son périmètre à ce que son nom autorise. "Équipe Performance" dit immédiatement son objectif. Toutes les équipes se sentent concernées.

"Quand tu dis qu'il y a une équipe performance, tout de suite, tu comprends que ce n'est pas une personne ou une autre où vraiment tu vas attaquer tous les problèmes de la même façon."Jean-Baptiste Ronssin

Ce que Jean-Baptiste décrit, c'est une équipe dont le mandat est horizontal par construction, pas au service du CRO (Chief Revenue Officer, directeur des revenus), mais au service de l'entreprise dans son ensemble.

2. Traiter le collaborateur interne comme un client : une posture qui change tout

Cette idée est revenue plusieurs fois dans l'échange, et je comprends pourquoi Jean-Baptiste y insiste.

La plupart des équipes OPS sont évaluées sur des projets. Elles produisent des outils, des process, des automatisations. Ce qu'elles font moins bien, c'est comprendre si leurs livrables sont réellement utilisés. Jean-Baptiste propose de traiter chaque collaborateur interne comme un client : comprendre ses attentes, mesurer sa satisfaction, rendre un service. Cette posture change la façon d'arriver dans une réunion, de formuler une recommandation, et de mesurer son propre impact.

Être au service d'un client interne ne veut pas dire acquiescer. Il est explicite là-dessus : être au service peut vouloir dire non. La posture de service inclut la capacité à challenger, à refuser ce qui ne sert pas l'organisation, et à défendre un sujet face à des niveaux hiérarchiques élevés. C'est une posture, pas une fonction.

3. Sous quelle direction rattacher l'équipe Performance pour éviter le biais

C'est la question que j'avais envie de poser depuis le début, et la réponse m'a surpris par sa précision.

Jean-Baptiste écarte le rattachement sous le CRO pour une raison structurelle : si l'équipe OPS définit et contrôle les objectifs sous la direction de celui qui les subit, elle se retrouve "jugée partie." Le biais n'est pas toujours conscient. Il opère au moment de fixer ce qu'on peut évaluer. Il mentionne avoir eu trois managers simultanément, CEO, CTO (Chief Technical Officer, directeur technique) et CRO, ce qui rendait la priorisation des projets impossible à coordonner.

Son organisation idéale est une direction Performance rattachée directement au CEO, ou une direction complètement séparée. Le CEO n'est pas teinté par un agenda sectoriel. Il est là pour que l'entreprise fonctionne, ce qui est précisément l'objectif de l'équipe Performance.

4. Quand recruter son premier OPS et combien en avoir

Le ratio de 1 pour 15 est souvent cité. Jean-Baptiste l'utilise, mais il le recadre : c'est 1 pour 15 clients internes, pas 1 pour 15 sales.

Le vrai signal de recrutement. Ce n'est pas un seuil de headcount. C'est le moment où ajouter un commercial n'augmente plus les revenus dans la même proportion. Quand l'organisation "consomme de la performance commerciale" au lieu d'en produire, il faut agir avant que les process s'effondrent.

Comment démarrer sans budget dédié. Un consultant externe pendant un à deux ans peut poser les bases à moindre coût. Autre option : identifier en interne quelqu'un qui a la fibre, souvent un ancien commercial. Mais Jean-Baptiste nomme le risque clairement : un OPS issu du terrain non formé ne résoudra que les problèmes qu'il a lui-même subis, et rien d'autre.

5. Run vs Build : le ratio qui révèle la santé réelle d'une équipe Ops

C'est l'idée la plus opérationnelle de l'épisode, et celle qui me semble la plus difficile à appliquer.

Le run désigne tout ce qui est réactif : tickets, maintenance, demandes entrantes. Le build désigne tout ce qui est proactif : nouveaux process, automatisations, architecture durable. Jean-Baptiste estime que l'idéal est 60 à 70% de build pour 30 à 40% de run. Dans la réalité, la plupart des équipes sont à l'inverse, 30% de build et 70% de run, parce qu'elles ont été recrutées trop tard ou ont absorbé trop vite des responsabilités de maintenance.

Un ratio de run trop élevé a des conséquences directes : les profils s'ennuient, stagnent et partent. Les objectifs ne portent que sur 30% de la capacité réelle de l'équipe. Et l'organisation se prive de la partie du travail OPS qui crée de la valeur durable. C'est un cercle vicieux qui commence presque toujours par un manque de vision moyen terme.

6. Comment évaluer une équipe Ops : build, satisfaction interne et 360°

C'est la question la plus difficile de l'épisode, et Jean-Baptiste est le premier à le reconnaître.

Évaluer sur le build est relativement simple : objectifs de projet par trimestre, mesure de l'utilisation des livrables. Évaluer sur le run est plus complexe, parce qu'une partie du run est nécessaire et invisible, un système de facturation, le respect d'un process légal, et ne génère aucun enthousiasme des équipes qui la subissent.

Jean-Baptiste recommande une évaluation en deux volets : des objectifs de projet sur le build, et une satisfaction interne mesurée en 360° où les collaborateurs OPS sont évalués par leurs managers, leurs pairs, et les équipes clientes avec lesquelles ils travaillent. Sur le commissionnement, il est prudent : il a observé trop de cas où des Ops commissionnés sur la performance commerciale finissaient par faire une partie du travail de leurs équipes clientes, ce qui améliore les chiffres, mais pour de mauvaises raisons.