Les développeurs sont devenus des cols bleus

Et c’est bien dommage…

Les développeurs sont des gens formidables: quand ils sont motivés par un projet ils sont prêts à se donner à fond, à ne pas compter leurs heures, voire à travailler dessus en dehors des heures de bureau. Ils ont une véritable passion pour les problèmes complexes et adorent construire des solutions innovantes pour les déjouer. Un développeur motivé peut abattre le boulot de 10 développeurs pour qui le projet ne représente rien. L’implication émotionnelle des développeurs est un puissant moteur pour l’entreprise: s’ils adorent le projet, il lui consacreront bien plus que ce que leur contrat de travail leur impose. En revanche, s’ils le détestent, ils deviendront des “yes men” taciturnes et râleurs, et freineront des deux pieds quand on viendra leur demander quoi que ce soit.

Et il serait réducteur de considérer la rémunération comme une motivation suffisante. Un salaire plus élevé est indéniablement un avantage, mais dans l’état actuel du marché où c’est surtout le développeur qui choisit son entreprise et non l’inverse, le projet et l’intérêt qu’ils peuvent susciter est au tout premier plan de la motivation et donc de l’implication du développeur. Cet intérêt n’est pas lié à un secteur plutôt qu’un autre. Je bosserais volontiers dans la comptabilité si on me vendait un projet passionnant car finalement, peu importe le sujet et le secteur d’activité tant qu’il y a le challenge !

Mais qu’on s’entende bien sur la définition de “challenge”. J’ai été démarché des dizaines de fois pour des postes de maintenance applicative, donc à faible valeur ajoutée, avec des annonces qui mettaient en avant le “défi technique” posé par le projet. Mais quand ce défi consiste exclusivement à être capable de rustiner une application mal conçue ou en fin de vie, ce n’est pas motivant. Clairement, oui, c’est très compliqué de maintenir ce genre d’application, mais cette difficulté ne correspond pas vraiment à ce que j’appelle ici un défi. Imaginez que pour recruter un chirurgien on lui propose la description de poste suivante:

Recrute: Chirurgien Viscéral

Mission: Nous recherchons pour un de nos client en milieu hospitalier un chirurgien viscéral spécialiste des ablations de l’appendice. Votre mission consistera exclusivement à pratiquer des appendicectomies et vous effectuerez la prise en charge intégrale du patient depuis son admission jusqu’à sa sortie. Vous serez également responsable de l’hygiène du bloc opératoire, de la stérilisation des instruments, de la rotation de la literie de vos patients, de leur toilette et resterez à leur disposition en dehors des heures de présence dans l’hôpital sur simple demande de leur part.

Profil: Titulaire d’un doctorat et de 12 ans d’expérience en chirurgie hospitalière, vous êtes rigoureux et autonome. Vous nourrissez une passion pour l’appendicectomie et vous aimez le défi que présente la prise en charge en urgence. Vous savez conserver votre sang froid dans les situations délicates et êtes parfaitement capable de pratiquer seul une opération ou de vous former aux nouvelles pratiques de chirurgie. D’un naturel sociable, vous êtes parfaitement à même de recueillir les besoins du patient et d’adapter vos heures de consultation et d’opération à leur convenance.

Ça vous paraît absurde ? J’en reçois au moins dix par semaine des comme ça. Donc non, une tâche rébarbative, difficile et absente de tout processus créatif n’est pas ce qu’on peut appeler un défi. Il est difficile de s’imaginer, de se projeter dans le projet et l’entreprise quand le poste proposé est d’emblée une “voie de garage”. Or, c’est justement cette capacité à se projeter dans le projet, à s’imaginer faire partie d’une aventure qui est la source de cette formidable motivation dont je parlais tout à l’heure. Il faut donc faire en sorte que cette motivation soit possible, mais comment ? Peut être faudrait-il arrêter de voir un développeur comme un ouvrier qualifié sur une chaîne de montage, comme un col bleu.

Le clivage col bleu / col blanc

Col bleu (classe sociale): De nos jours, l’expression col bleu est un terme d’argot utilisé pour désigner des individus faisant partie du bas de la hiérarchie de l’entreprise, en particulier les ouvriers et les exécutants des tâches manuelles, par opposition aux cols blancs qui en représentent les dirigeants et les cadres. […] Le terme col bleu provient de l’habit de travail des ouvriers, une combinaison de toile bleue portée pendant le travail.

(Source: Wikipedia)

Clarifions d’emblée un point important: il est très fréquent de voir des développeurs embauchés en tant que cadres, mais il s’agit moins ici de refléter leur fonction dans l’entreprise que de contourner la rigidité du droit du travail en matière de temps de travail. Ce qui signifie qu’on peut être cadre sans être pour autant décisionnaire ou amené à encadrer du personnel.

Vous l’avez peut être vous-même ressenti, il y a toujours dans notre pays une mentalité de cloisonnement, comme si chaque acteur de la société avait une tâche qui lui est propre et à laquelle il ne doit pas déroger. On aime les étiquettes à tel point que la première question qui vient dans une conversation avec un inconnu est presque toujours “et sinon tu fais quoi dans la vie ?” Que ce soit une bonne ou une mauvaise chose n’est pas vraiment le débat qui nous occupe. En revanche, on va essayer de s’intéresser aux effets de cette mentalité dans le monde du digital.

Les développeurs sont souvent vus par leurs collègues et leur hiérarchie comme des ouvriers, des cols bleus. Leur tâche consistant à construire un outil qui servira le business mais qui ne constitue en soi aucune valeur. On me l’a d’ailleurs déjà dit en face: “en fait, ton boulot c’est de fabriquer nos outils”, comme si je ne participais pas à la création de valeur dans l’entreprise, que la seule valeur était produite par ceux qui utilisent l’outil pour faire du chiffre… Et vu sous cet angle, la technique n’est effectivement qu’un coût et rien d’autre pour l’entreprise. Coût qu’il convient de mesurer, de réduire et d’optimiser au mieux. Finalement, quelle différence avec un ouvrier qualifié ? Son rôle est indispensable, mais l’ouvrier lui est interchangeable.

Or il n’y a rien de plus éloigné de la réalité. Même si le produit technologique ne constitue pas toujours la valeur principale de l’entreprise, la technique est toujours nécessaire pour permettre d’en créer. A quoi ça sert d’être chauffeur de taxi si on a pas de voiture ? De plus, il faut un certain temps pour qu’un développeur devienne efficace dans l’entreprise et qu’il s’approprie le projet et comprenne les enjeux et contraintes de l’entreprise. Ce n’est qu’à partir de ce moment là qu’il devient vraiment efficace, ce qui fait que son remplacement est souvent problématique car avec lui part une partie du savoir-faire, et donc de la valeur. On est assez loin de la définition d’un ouvrier qualifié non ?

Malgré tout, les développeurs intériorisent souvent ce rôle de col bleu et il est rare de les voir remettre en question la place qu’ils occupent dans l’entreprise. En général ils ne participent pas aux décisions qui ne concernent pas directement la technique et ne sont pratiquement jamais consultés sur des questions d’orientation. Pour évoluer dans l’entreprise, un développeur doit généralement quitter la technique, arrêter de coder et se mettre au management.

Cet état de fait entretient le clivage entre techniques et opérationnels et, dans certains cas, peut conduire à la formation de clans au sein de l’entreprise. Clans dont les membres se haïssent par principe: “de toute façon, ils comprennent rien à ce qu’on fait. C’est pas la peine de parler avec eux.” Quand on en est là, inutile de parler de collaboration et de synergie au sein de l’entreprise. Je l’ai souvent constaté, les techniques et les non-techniques se mélangent peu.

Inutile d’être expert en management pour comprendre que le projet, et par extension la boite tout entière finissent par en pâtir.

Communication is key

Il faut comprendre que les disciplines techniques et opérationnelles sont par nature dépendantes les unes des autres. Elles ne doivent pas simplement coexister mais s’intriquer, s’entremêler a tel point qu’un œil extérieur ne saurait plus distinguer le commercial du développeur. Je ne préconise pas pour autant de détruire la notion de rôle dans l’entreprise, chaque intervenant disposant de domaines d’expertise qui lui sont propres. Mais c’est justement la mise en commun de tous ces talents qui font les projets réussis.

Il est donc primordial que tout ce petit monde se parle, échange et confronte ses idées; les expose (sans les imposer) afin qu’un consensus émerge. Pour que ce consensus puisse exister et être accepté par tous (et non subi par certains) il faut que la philosophie de l’entreprise permette ce dialogue:

• la hiérarchie au sein des membres du projet doit être aussi horizontale que possible afin que les idée soient exprimées librement et sincèrement, il faut éviter que de bonnes idées passent à la trappe à cause de la “crainte du boss” ;
• un leader doit exister au sein du groupe afin de trancher sur les questions qui le mettent dans l’impasse et recadrer les débats un peu trop houleux. Son rôle est de maintenir l’harmonie et la bonne entente, pas d’imposer sa vision ;
• la responsabilité doit être diluée au sein de tout le groupe, si quelque chose se passe mal, c’est la faute de tout le groupe et non celle d’un seul membre, ceci afin que tout le monde se sente impliqué et responsable ;

Quand on bosse dans cette optique, on se rend compte que les fonctionnalités sont livrées beaucoup plus vite car elles sont le fruit d’une réflexion plus aboutie en amont et d’un suivi plus précis en aval, évitant de fait le back-and-forth inutile entre producteurs (les développeurs) et clients (les opérationnels). De plus cela permet à chacun de s’enrichir à travers une ouverture et une vision qu’ils n’auraient jamais eu s’ils s’étaient cantonnés à leurs seuls domaines d’expertise. Les techniciens comprennent mieux les besoins métier et sont plus à même de fournir des solutions efficaces, et les opérationnels comprennent mieux le fonctionnement, les forces et les faiblesses de l’outil, et sont donc capable d’adapter leur stratégie et leur discours en conséquence. Tout le monde y gagne et en sort grandi.

Beaucoup de méthodologies comme KanBan et Scrum exigent pour être efficaces que ce dialogue entre technique et métier existe. De là à dire que la vision développeur = col bleu est responsable de l’échec de ces méthodologies dans bon nombre de boites françaises, il n’y a qu’un pas. De plus, beaucoup d’entreprises font le pari de capitaliser sur la connaissance. Il existe d’ailleurs aujourd’hui un métier pour ça: celui de Knowledge Manager. Il est donc important de valoriser les compétences techniques de la même façon que l’expertise métier. Je suis convaincu qu’en dépassant cette vision négative de la technique nos entreprises pourraient être bien plus agiles, compétitives et humaines, à l’image des start-up de la Silicon Valley.

Sur ce, je vous laisse méditer sur cette citation de Sacha Boudjema qui illustre bien ce qu’on a tous à gagner à partager nos savoirs, dans l’entreprise comme ailleurs:

La connaissance est la seule chose qui s’accroit lorsqu’on la partage.