3 Mensonges Que Votre Équipe Technique Vous Raconte (et Qu’Elle Se Raconte à Elle-Même)

« C’est ainsi que Google fait ses pages de destination. C’est la norme du secteur. » 

« Nous ne pouvons pas livrer plus tôt qu’en août. Nous avons additionné nos estimations et six mois, c’est ce que nous avons obtenu. » 

« Attends juste deux semaines pour cette correction urgente. Nous ne pouvons pas rompre le sprint, sinon nous ne serons plus Agiles. » 

Chacune de ces phrases est un mensonge que votre équipe technique vous raconte—et se raconte à elle-même. Ces malentendus très courants découlent d’une erreur fondamentale répandue chez les ingénieurs : la croyance en ce qui est « mieux ».

Mieux n’est pas mieux (pour tout le monde)

À l’intérieur d’un ordinateur, c’est le royaume du zéro et du un. Il n’y a aucun doute ou incertitude sur l’arithmétique et les portes logiques et, sauf l’exception d’un rayon cosmique occasionnel, la machine est entièrement déterministe, suivant le même chemin encore et encore chaque fois que vous fournissez les mêmes entrées. 

Même l’aléatoire apparent dans les jeux ou les simulations n’est en réalité qu’une illusion. Si vous fournissez une « graine pseudo-aléatoire » à, par exemple, Minecraft, vous obtiendrez exactement le même comportement à chaque nouvelle partie. Il est utile de se rappeler que chaque membre de votre équipe informatique a choisi un métier qui implique ce niveau de certitude et de prévisibilité ; il est littéralement impossible d’exercer leur métier sans raisonner rigoureusement à partir des premiers principes.

Mais en dehors du domaine computationnel, nous sommes confrontés à des humains imprévisibles, et toutes les règles tombent. Aucune équipe commerciale ne songerait à utiliser la même présentation ou argumentaire pour chaque prospect, et chaque appel du service client est différent et surprenant. Les scripts et formations aident votre personnel à offrir de la cohérence, certes, mais il est crucial d’adapter l’approche à chaque situation, comme tant d’organisations l’ont découvert à leurs dépens en tentant d’adopter l’holacratie ou les méthodes lean pour émuler le succès de Zappos et Toyota, avant de tomber à plat.

C’est tout aussi vrai dans le développement logiciel que dans les opérations, la finance ou la stratégie : il n’existe pas une seule bonne façon de concevoir un écran de connexion, de générer un rapport, ou de découvrir quelles fonctionnalités vos clients accepteront de payer. C’est pourquoi les ingénieurs ont inventé tant de méthodologies logicielles différentes, comme Scrum, Kanban, ShapeUp, le modèle Spotify, SAfE et une centaine d’autres, toutes couronnées de succès dans certains cas et désastreuses dans d’autres.

Vous comprenez maintenant pourquoi nous, les techs, tombons dans le piège du « mieux ». Chacun de nous trouverait séduisant de croire qu’il existe quelque part une tablette gravée contenant la réponse à nos problèmes, mais la certitude est dangereusement attirante lorsque l’on travaille au quotidien avec des outils et des machines dont le fonctionnement dépend d’une cohérence absolue. Mais comment se défaire de ce réflexe de pensée binaire ?

D’abord, questionnez sans relâche

Pour beaucoup d’entre nous, la technologie relève de la magie noire. Les ingénieurs marmonnent des incantations bizarres sur Kubernetes et les zettaoctets, et du néant surgissent des sites web, des mails et des paiements par carte bancaire. Alors, quand les sorciers nous affirment suivre « les meilleures pratiques », qui sommes-nous pour les contredire ?

La réponse, c’est VOUS ! Comme tout autre membre de l’équipe, les développeurs ont besoin de retours sur la conformité de leurs plans et livrables avec la stratégie de l’entreprise. Vous n’avez pas besoin de parler le langage des geeks pour apporter vos réactions et orientations ; c’est leur rôle d’apprendre assez sur votre marché et vos objectifs pour pouvoir vous rendre des comptes efficacement, en français courant. N’ayez pas peur de poser toutes sortes de questions sur leurs priorités, les raisons qui motivent le choix de telle ou telle technologie, et surtout, la façon dont ils estiment que l’entreprise en bénéficiera. 

Je crois tellement à la puissance du questionnement que j’ai fait imprimer de jolis certificats dorés donnant l’autorisation officielle de questionner les ingénieurs sur n’importe quel sujet, et je les distribue dès que possible. Voici un exemple ci-dessous. Si vous souhaitez en avoir un à accrocher dans votre bureau, envoyez-moi un e-mail et je vous en ferai parvenir un (gratuitement !) 

Ensuite, jouez au jeu des « pourquoi »

Une fois la peur des questions vaincue et que vous en avez appris davantage sur la démarche de votre équipe technique, il est temps de jouer au jeu du « pourquoi ». Les règles sont simples et connues de tous les enfants de cinq ans : commencez par demander ce que fait un développeur, puis enchaînez les « pourquoi » à répétition. 

« Je remplace notre page de paiement. »

« Pourquoi ? »

« Parce qu’elle est inefficace. »

« Pourquoi est-elle inefficace ? »

« Nous faisons des vérifications inutiles qui ralentissent nos temps de réponse. »

« Pourquoi la rapidité est-elle importante ? »

« Parce que les utilisateurs abandonnent lorsqu’ils doivent attendre trop longtemps pour payer. »

Le signal d’arrêt, c’est l’argent. Dès que vous entendez : « parce que cela augmentera les conversions », « parce que plus de clients passeront à la version supérieure », ou « parce que nous allons réduire les coûts de recherche », vous avez gagné. Si vous n’y arrivez jamais, et que vous finissez par un « je ne sais pas » ou « parce que Jane l’a dit, » vous (et non l’ingénieur) avez perdu au jeu du pourquoi. Cherchez des moyens de connecter votre équipe technique beaucoup plus étroitement aux résultats de l’entreprise afin que tout le monde sorte vainqueur la prochaine fois que vous jouez.

Après quelques séries de pourquoi, vous commencerez à voir les schémas et les manques. Par exemple, j’ai travaillé avec une équipe qui était obnubilée par l’augmentation de son taux de conversion, mais ignorait totalement les coûts. Sans surprise, ils ont explosé leur budget avec des stratégies publicitaires sociales hyper-optimisées beaucoup trop compliquées pour une simple campagne de Noël.

Certes, leurs algorithmes sophistiqués étaient « meilleurs » pour obtenir un léger avantage sur certains mots-clés, mais la facture Facebook a vite ramené tout le monde à la réalité (y compris des frais pour avoir littéralement fait planter certains serveurs publicitaires de facebook.com avec trop de requêtes !). Quand vous repérez de tels angles morts, corrigez les priorités, annulez ce qui est inutile, et rappelez que la technique doit rester fermement alignée sur les objectifs business.

Enfin, assurez la responsabilité

Maintenant que vous avez identifié et supprimé les solutions techniques « meilleures » qui ne fonctionnent pas vraiment pour vous, offrez aux ingénieurs des moyens simples de vous prouver qu’ils restent alignés et dans la bonne direction. Vous remarquerez que je n’ai pas parlé de « demander des comptes à l’équipe technique », une approche accusatrice qui me donne toujours envie de me cacher sous le bureau le plus proche. À la place, permettez à vos développeurs d’être responsables devant vous. Par exemple :

• Planifiez une démonstration hebdomadaire des améliorations informatiques, les responsables d’équipe exposant les bénéfices métier et recueillant vos retours et ceux des autres.
• Mettez en place un tableau de bord affichant des indicateurs clés comme la disponibilité du système ou le nombre d’appels répondus, et demandez aux développeurs d’expliquer régulièrement comment leurs actions améliorent les résultats.
• Créez un glidepath pour suivre les progrès sur les projets clés et rebondir rapidement si des éléments sont retardés.

Une stratégie claire pour des retours fréquents et un accent mis sur des bénéfices métiers concrets et tangibles vous garantira que votre budget IT n’est pas gaspillé dans des projets « malins » mais inutiles. Et si, comme la plupart des entreprises que je rencontre, vous dépensez des millions dans la tech pour des résultats au mieux flous, ne vaudrait-il pas mieux mesurer votre retour sur cet immense investissement ?

Abonnez-vous à la newsletter du CTO Club pour plus de conseils de notre communauté.