"La tech, c'est ingrat. Il faut l'accepter."
Cela s'applique en réalité à toutes les fonctions support
J’ai entendu cette phrase de la bouche de Joanne Deval lors d’un événement de la communauté “Les Pros de la Transfo” organisé par AirSaas.1
J’ai adoré comment elle a amené ce propos de manière abrupte, avant de l’étayer de ses expériences dans des rôles comme DSI. Car oui, cela ne sert à rien d’essayer d’enjoliver la réalité : être DSI, c’est-à-dire travailler dans la tech d’une entreprise dont le domaine métier n’est pas la tech, c’est fondamentalement ingrat — et il faut être OK avec ça, ou changer de métier ou d’entreprise.
Les discussions tournaient autour du rôle de DSI car il est représentatif, et cela correspondait au public cœur de l’événement. Ces propos sont une excellente piqûre de rappel. Néanmoins, pour moi, ils s’appliquent plus largement, au-delà du cas du rôle de DSI.

Les entreprises qui ne vendent pas de la tech
Tout d’abord, quand on dit DSI on pense à des entreprises déjà établies. Or, de mon expérience, ces propos s’appliquent tout autant en start-up et en scale-up. J’ai notamment connu de l’intérieur :
WeMaintain, qui révolutionne le marché de la maintenance des bâtiments
Stairling, qui crée un nouveau modèle salarial à la faveur des travailleurs indépendants, notamment les VTC
Start-up oblige, la tech est clé dans ces entreprises. Une de leurs forces est justement de s’appuyer sur la tech pour développer un business model et des propositions de valeur innovantes.
Pour autant, tout ce que nous a partagé Joanne fait totalement écho aux dynamiques de ces start-ups. Logique : dans ces start-ups aussi, le tech est une fonction support au service des métiers, de ceux qui font tourner la boutique.
Je n’énonce absolument pas cela comme un problème. Comme l’a si justement dit Joanne : c’est ingrat, c’est comme ça, il faut en être conscient et l’accepter.

À une époque j’aimais bien dire qu’il y avait en France une certaine perception selon laquelle “la tech, c’est sale.” J’en blaguais en disant que lors d’un dîner de famille c’était presque honteux d’avouer travailler du côté des développeurs, quand les chefs de projet et autres MOA étaient vu comme la tête pensante, comme la partie noble du travail. J’en rajoutais peut-être un peu en disant ça… Et en même temps cela illustrait bien cette vision rétrograde où le métier de développeur était perçu comme un exécutant, le fameux pisseur de code.
Depuis, j’ai bien sûr fait évoluer ma vision des choses. Mais surtout, cette vision de rôle ingrat évoquée par Joanne est bien plus nuancée et juste.
Le rôle de la tech est essentiel : ce n’est pas un business tech mais le business repose sur la tech ; sans tech il n’y a plus de business. Pour autant le rôle restera toujours ingrat, culturellement et en pratique.
On peut construire une dynamique où l’on n’est pas en rôle d’exécutant, mais n’espérons pas devenir la tête de proue.
Un rappel de tous les jours…
Honnêtement, cet état de fait est une bonne chose.
Car ce qui fait la différence entre une fonction support qui a sa place au COMEX, et une fonction support qui ne l’a pas, c’est la capacité à parler la langue du business, à comprendre ses besoins, à s’engager sur ce qui compte vraiment et à ne pas se défiler face aux difficultés : bref, à se comporter en véritable partenaire du business.2
Ou comme a pu le dire Arnaud Lemaire, alors CTO de la scale-up Sunday : ”Tech et Business, on doit être du même côté du flingue.” 3
Ce que l’on attend d’une fonction support pour mériter sa place au COMEX, c’est de jouer le même jeu que le reste du COMEX.
Qualité numéro 1 : fiabilité.
Être fiable. Oser s’engager, et tenir ses engagements 💪
Ne pas faire porter la responsabilité sur d’autres entités ou sur des prestataires en cas de soucis ; au contraire, assumer un ownership sans faille sur les résultats.
👉 Ses actions démontrent que l’on se sent concerné par le business.
Qualité numéro 2 : communication.
Être transparent, de manière compréhensible et au bon niveau 🧠
Ne pas rajouter une charge mentale de plus au mais au contraire construire une abstraction qui marche : on articule clairement ce que ça apporte au business, et les conditions nécessaires pour y arriver.
👉 On ne parle pas le langage de la tech, mais le langage du business.
… Pour toutes les fonctions support
Ce partage de Joanne a continué de me trotter dans la tête. Non seulement j’élargis le constat à la tech en général et pas seulement aux DSI, je pense que cela s’applique également à l’ensemble des fonctions support.
Quand j’écris ça, je pense en particulier à un milieu que je connais bien : celui des Scrum Masters et coachs agiles. Depuis quelques années, ce sont des rôles en déclin, de moins en moins demandés, de moins en moins rémunérés.
Au-delà du renommage du rôle tellement est devenu chargé et connoté négativement, le changement que j’ai vu est l’exigence d’être redevable de résultats. C’est ainsi que c’est maintenant des rôles comme Delivery Manager qui ont le vent en poupe, pour au final faire la même chose — l’exigence de s’engager sur les résultats en plus !
J’ai donc envie de continuer le parallèle entre les propos de Joanne et ces rôles de Scrum Master et coach agile : on veut toujours de ces rôles, quitte à les renommer, mais surtout à la condition qu’ils soient pris dans le sens du business.
On ne veut pas de quelqu’un qui protège l’équipe ;
on veut de quelqu’un qui ose s’engager sur des jalons quand il le faut
et qui fait le nécessaire pour qu’ils soient tenus.
Je n’écris pas ces mots à la légère ni en reniant le fameux rythme soutenable si cher aux agilistes.
La réalité du terrain, c’est d’avoir des périodes de rush ou de crunch.
Ce qui fait la différence c’est :
Comment les gérer de la meilleure manière possible, autant du point de vue des résultats que du respect des individus
Comment faire en sorte que cela soit exceptionnel et non pas la normalité
Comment faire passer en priorité les enjeux du business, sans tomber dans la toxicité
Mais tout ça, cela n’intéresse pas votre DG ou votre CEO. Voici ce qui l’intéresse :
Est-ce que tu peux faire que ça marche ?
Si votre réponse est oui, c’est tout ce dont il ou elle veut savoir.
À propos de l’événement : (post LinkedIn par Thomas Poitau)
https://www.linkedin.com/posts/thomaspoitau_on-a-les-sponsors-quon-m%C3%A9rite-activity-7420358976791355392-gqMD
Lien vers la communauté “Les Pros de la Transfo” : https://www.airsaas.io/fr/lesprodelatransfo
Je les connais depuis quelques années déjà et je suis aligné avec leur philosophie !
AirSaas apporte également une vue rafraîchissante avec le Quarter Plan, avec en tête comment mettre en place un cadencement qui permet d’aligner business et tech, enjeux et capacité à faire.
Je me dois de préciser que dans ce paragraphe je paraphrase Joanne !
Encore merci à elle 🙏
Qui plus est lors de l’événement elle avait étayé ses propos d’anecdotes puissantes, très appréciables.
Arnaud Lemaire a fait une apparition imprévue lors d’un live hebdomadaire de Scrum Life. Comme à son habitude, il a enchaîné banger sur banger. Voici le lien vers l’enregistrement : https://youtube.com/live/Sh4psp8K2VM


Ce que je vois au dessus de ces qualités de fiabilité et de communication c’est la notion de vérité.
Faire ce que je dis, dire ce que j’ai fait en ayant en tête que c’est la vérité du terrain, du business qui validera les actions et les paroles émises en amont
Je ne vois pas forcément la tech comme une chose ingrate mais je peux comprendre ce point de vue. En tout cas si on veut exceller dans ce domaine, la recherche de vérité qui ne nuit pas au produit, à l’équipe, est pour moi son aspect le plus exigeant et le plus gratifiant