Depuis plusieurs années que je suis consultant chez OCTO, j’ai eu plusieurs fois l’occasion d’auditer le fonctionnement d’équipes de développement, que ce soit pour des audits internes ou des due diligences techniques.
Dans ce contexte, j'ai pu constater un comportement récurrent dans de nombreuses entreprises, notamment chez les startups numériques.
Ma définition :
C'est ce que j'appelle faire du développement en vase clos. En effet, à aucun moment l’équipe n’a reçu de nouvel apport extérieur, aucune nouvelle personne ne venant partager avec l'équipe ses expériences passées et son savoir-faire.
A l’instar des pharaons égyptiens et de certaines familles royales qui souhaitaient préserver la "pureté de leur sang" et qui pratiquaient la consanguinité, les systèmes informatiques ainsi conçus comportent malheureusement de nombreuses tares (liste non exhaustive, sur la base d’exemple que j'ai rencontrés) :
En règle générale, plus le développement du produit se fait rapidement/dans l’urgence, plus ces tares sont nombreuses.
Ce mécanisme n’est pas réservé aux start-ups, j'ai pu constater les mêmes problèmes dans des sociétés utilisant des développeurs ou des développeuses en prestation dont le critère principal de sélection est le tarif journalier moyen.
Ce mode de fonctionnement repose sur quatre raisonnements erronés (et certainement plus), appliqués de manière plus ou moins consciente :
Par opposition aux quatre raisonnements développés dans le précédent paragraphe, mon opinion est la suivante :
Ne pas investir sur l'apprentissage des développeurs et des développeuses aux pratiques de développement puis ne pas les accompagner dans leur progression, c'est les empêcher de développer leurs talents en programmation. Certaines sociétés assument ce parti pris, mais en payent souvent les conséquences à moyen ou long terme quand leur time to market explose ou qu’ils sont incapables de maintenir leurs applications.
Dans le même ordre d'idée, les écoles/formations en programmation dans lesquelles il n'y a aucun accompagnement par un développeur ou une développeuse expérimenté·e et où l'auto-formation et l'évaluation par les pairs sont la règle ne peuvent que transmettre une vision biaisée. En effet, cela peut donner l'impression aux étudiants et étudiantes qu'une progression uniquement par soi-même et/ou en vase clos est possible. Or, comme je l'ai déjà dit en introduction, c'est se condamner à accepter d'évoluer dans des entreprises qui prônent, consciemment ou pas, la consanguinité logicielle et ses conséquences. Pour résumer ma pensée, une école/formation/entreprise où des débutants aident d'autres débutants à débuter dans la profession réduit fortement la montée en compétence de ces derniers et l’expression de leurs talents…
Pour devenir un développeur ou une développeuse professionnelle, il y a trois axes essentielles:
D'un côté, si l’on suit les préceptes de Sandro Mancuso (cf. The Software Craftsman) ou Bob Martin (cf. Clean coder), en tant que développeur ou développeuse, il est donc de notre responsabilité individuelle de trouver ou créer un environnement où les actions de ces 3 axes sont possibles. De l'autre, à l’opposé de la vision de ces auteurs, je trouve que c’est de la responsabilité de l’employeur d’être acteur de la progression de ses salariés et de créer les conditions de leur mise en place :
Un moyen simple pour s’affranchir du vase clos et s'ouvrir aux influences extérieures : participer à des événements communautaires. Que ce soient des conférences, des meet ups ou des coding dojos, c'est l'occasion de faire connaissance avec ces nouvelles pratiques ou des nouvelles technologies. Cela peut même être l'occasion d'être initié et accompagné dans une première phase d'apprentissage, notamment dans les coding dojos ou les conférences de type "Hands on".
Encore une fois, la responsabilité porte sur le développeur ou la développeuse mais aussi sur la société qui l'emploie. C’est un élément important de veille que de participer à ce genre d'événement. Il est judicieux que l'employeur (ou le client) donne l'opportunité à ses collaborateurs qui le souhaitent d’y aller (temps et moyens). Pour aller plus loin, il pourrait même s’engager à héberger dans ses locaux un événement communautaire ou encore de sponsoriser une conférence.
Toutefois, si l'on se focalise sur les pratiques de développement notamment, la dure réalité des projets fait qu'il est souvent difficile d'appliquer par soi-même ce que l'on nous a expliqué en conférence. Même si, dans le meilleur des cas, la direction de projet nous permet de prendre le temps pour les mettre en place et que l'équipe est motivée pour se lancer, il est souvent difficile de s'y mettre une fois seul. Les causes les plus courantes que j'ai pu observer sont les suivantes :
La veille (vidéos, blogs, livre, papiers de recherche) est aussi une forme d’ouverture vers l'extérieur. Toutefois, j'ai pu rencontrer des équipes qui déclaraient faire de la veille et qui présentaient tout de même les symptômes du fonctionnement en vase clos. En effet, dans ces cas, la veille était soit trop superficielle, soit focalisée sur des points très techniques. La veille très ciblée sur la technique peut renforcer l'opinion - consciente ou inconsciente - que le développement n'est qu'un savoir théorique.
Enfin, le recrutement en prestation de profils expérimentés peut être un bon moyen d’injecter des bonnes pratiques dans l’équipe. Mais encore faut-il pour cela qu’ils ou elles ne se fassent pas happer par la culture de l’équipe déjà en place. Dans ce genre de cas, j’ai pu observer malheureusement le départ anticipé des développeurs et des développeuses les plus aptes à faire sortir l’équipe du vase clos, ne restant que ceux qui adhèrent à la culture en place. Pour que cela fonctionne, il faut donc un mandat clair au prestataire, partagé par l’équipe en place : cette personne est là pour nous aider à progresser, prenons le temps d’écouter ce qu’elle a à nous proposer.
À ce stade, j’espère vous avoir donné les clés pour comprendre comment ne pas créer un environnement de consanguinité logicielle : former et accompagner les développeurs et développeuses juniors, mélanger les niveaux d'expertises, mettre en place du mentorat et inciter les équipes à participer à des événements communautaires. Que faire, par contre, si par un malheureux hasard, vous travaillez dans ou avec une équipe renfermée sur elle-même ?
Il faut d’abord commencer par un diagnostic externe, faire un état des lieux des douleurs. Ensuite, partager les résultats avec l'équipe, le management, la direction de projet (qu'on l'appelle Product Owner, Product Manager, Sponsor, chef de projet, MOA, CEO,…). S’il y a adhésion aux conclusions, d'un côté par les développeurs et développeuses à sortir du bricolage, de l'autre par la direction à l'importance de former des professionnels, vous pourrez envisager un plan d'action. Dans le pire des cas, c’est-à-dire une équipe ne connaissant aucune des pratiques de développement énoncées précédemment, il pourrait être de ce type :
Dans le cadre d'une équipe de prestataires, il arrive que le client impose ce genre de formation à ses fournisseurs ainsi qu'une partie de l'accompagnement.
Face au diagnostic d'un logiciel possédant les tares décrites au début de cet article, la fausse bonne idée serait de faire une refonte car l'équipe aura beau être plus expérimentée, sans apprentissage des pratiques de développement, elle continuera à reproduire le même génome …