De consultant marketing à codeur : pourquoi j'ai franchi une ligne que la plupart des gens ne franchissent pas
En bref : après plus d'une décennie à conseiller des marques sur l'image de marque, le marketing et la communication, à la fois en agence et en indépendant, je me suis heurté sans cesse au même mur : des développeurs capables de construire presque n'importe quoi, mais qui comprenaient rarement pourquoi une décision marketing ou design comptait réellement. Cette traduction entre nous avait un coût bien réel, en temps et en argent, encore et encore, à travers des équipes et des années différentes. Avec le temps, j'ai cessé de recruter pour combler l'écart, et j'ai commencé à le combler moi-même.
Le mur auquel je me heurtais sans cesse
Pendant douze ans, entre l'image de marque, le marketing et la communication, j'ai travaillé des deux côtés du monde de l'agence : à l'intérieur d'agences au service de nombreuses marques à la fois, et en indépendant, en conseil direct. Des salles différentes, des clients différents, le même mur.
Je transmettais une stratégie, une réflexion de design, la raison pour laquelle un titre devait dire exactement ce qu'il disait, et je la voyais arriver de l'autre côté du développement, changée d'une façon qui n'était pas anodine. Pas par malveillance. Juste perdue. Un développeur simplifiait quelque chose par commodité technique, sans se rendre compte qu'il en avait discrètement retiré tout le sens. Ou bien il construisait exactement ce qui avait été demandé, à la lettre, sans en comprendre le « pourquoi », et livrait quelque chose de techniquement correct mais stratégiquement erroné. Ou bien nous passions des jours, à deux, à traduire un élément de stratégie en un brief qu'une équipe de développement pouvait exploiter, et quelque chose se perdait tout de même dans ces allers-retours. Ou bien le travail était techniquement excellent et totalement indifférent à ce qu'il faisait réellement à la conversion ou à la marque.
Rien de tout cela n'était le fait d'un mauvais développeur ou d'un mauvais mois. C'était le même échec, sous des habits différents, répété sans cesse, à travers des équipes et des années différentes. Chaque fois que cela arrivait, cela coûtait du temps, cela coûtait de l'argent, et pire encore, cela coûtait au client une version du travail discrètement moins bonne que celle qui avait été conçue.
Pourquoi recruter autour du problème ne l'a jamais réglé
La solution évidente, c'est de mieux recruter, de rédiger des briefs plus exigeants, ou de trouver « le bon développeur ». J'ai essayé les trois, plus d'une fois. Elles aident à la marge. Elles ne règlent pas le problème structurel : un brief est une traduction, et toute traduction perd quelque chose. La personne qui le reçoit n'est jamais dans la pièce où la décision a été prise, si bien qu'elle comble les écarts avec ses propres suppositions raisonnables, et les suppositions raisonnables finissent par dériver.
Ce n'est pas un problème de recrutement. C'est un problème de distance. La seule solution qui règle vraiment les choses consiste à supprimer cette distance : placer la personne qui comprend pourquoi la décision a été prise sur le même siège que celle qui la construit.
La décision
J'ai donc pris la décision que la plupart des gens dans ma position ne prennent pas. J'ai cessé de confier le développement à quelqu'un d'autre, et j'ai appris à le faire moi-même.
Il n'y a eu ni bootcamp ni formation derrière cela. Je me suis formé directement sur du travail réel, en construisant pour de vrais projets à mesure que j'apprenais, plutôt que de m'entraîner d'abord sur des exercices jetables pour les appliquer ensuite. C'était plus lent et plus chaotique qu'une formation structurée ne l'aurait été, et cela signifiait apprendre en public, sur un travail qui comptait vraiment, sans filet de sécurité entre une erreur et le moment où un client la verrait. C'était aussi la seule façon qui comblait réellement l'écart, parce que chaque projet que je construisais était un véritable test pour savoir si la stratégie avait survécu au développement, et non la simulation d'un tel test.
Ce qui a vraiment changé
La différence n'était pas que mon code soit devenu meilleur que celui d'un développeur spécialisé. Il l'était rarement, et je n'ai jamais prétendu le contraire. La différence, c'était que plus rien ne se perdait. Le raisonnement derrière une décision n'avait plus besoin de survivre à une transmission, parce qu'il n'y avait plus de transmission. La personne qui comprenait pourquoi quelque chose comptait était la même que celle qui le construisait, si bien que le « pourquoi » n'avait plus jamais à être traduit, et n'avait plus jamais l'occasion de dériver.
Voilà tout l'argument en faveur de ce passage de la ligne, du consultant au développeur. Pas qu'une seule personne puisse construire mieux qu'un spécialiste. Mais qu'une seule personne, tenant les deux bouts d'une même décision, cesse de perdre ce qu'un relais perd toujours.
Questions fréquentes
Parce que le problème n'était pas la qualité des développeurs avec qui je travaillais. C'était la distance. Un cahier des charges est une traduction, et toute traduction perd quelque chose, quelle que soit la compétence de la personne qui le reçoit. La seule véritable solution était de supprimer entièrement l'étape de traduction.
Plusieurs choses qui se chevauchaient, et toutes revenaient à répétition : l'intention de design et d'expérience discrètement dépouillée par commodité technique, un travail construit exactement comme demandé à la lettre sans comprendre pourquoi il importait, des allers-retours lents et coûteux pour traduire la stratégie en cahier des charges technique, et un travail techniquement solide qui ignorait son effet réel sur la conversion ou la marque.
Non. J'ai appris par moi-même directement sur de vrais projets, en construisant pour du travail client réel à mesure que j'apprenais plutôt qu'en m'exerçant séparément d'abord. C'était plus difficile, mais cela signifiait que chaque compétence acquise était immédiatement mise à l'épreuve d'un travail qui comptait.
Ce n'est pas sans risque, et c'était plus lent par endroits qu'un cours structuré aurait pu l'être. Mais c'était aussi la seule façon de véritablement vérifier si un élément de stratégie avait survécu à la construction, car aucun projet de substitution ne remplaçait le vrai.
Non, et ce n'était jamais le but. L'affirmation n'a jamais été que je pouvais surpasser un spécialiste à la construction. C'était que posséder à la fois la stratégie et la construction signifiait que le raisonnement derrière une décision n'avait jamais à survivre à une transmission, car il n'y avait aucune transmission à laquelle survivre.
Les détails de cela m'appartiennent, mais passer d'une carrière de conseil établie à la construction concrète n'est pas un mouvement courant, et il est juste de dire que cela a fait sourciller. Ce sont les résultats qui ont tranché.
Les deux. Ma propre expérience m'était propre, mais le problème sous-jacent, à savoir qu'un cahier des charges perd de l'information à chaque changement de mains, ne m'est pas propre du tout. C'est la même raison pour laquelle Thabrew Effect est construit autour d'un seul propriétaire tenant ensemble stratégie, design, construction et croissance.
Non. La leçon n'est pas "tout le monde devrait coder". C'est que partout où une décision doit franchir une transmission, quelque chose risque d'être perdu, et la solution est soit de supprimer la transmission, soit de veiller à ce que le raisonnement voyage délibérément avec elle. Pour moi, la supprimer était le bon choix. Ce ne sera pas le bon choix pour tout le monde.