Permettre le changement : à chaque situation sa typologie de mission

Dans les métiers de l'accompagnement, l'adaptation aux attentes et aux besoins du client est la clé d'une mission réussie. Je peux ainsi dire sans mentir qu'il n'y a pas deux missions identiques. Cependant, il reste possible d'identifier des typologies de missions, voici ce que cela pourrait donner.

"À l'aide, y'a tout qui brûle" : des développements qui prennent de plus en plus de temps et une inquiétante multiplication des bugs. On pense naturellement à un sujet de dette technique , et il y a toujours un sujet de dette technique. Mais, le développement se situant en bout de chaîne de la production logicielle, il est très visible et nous aurions tôt fait de croire qu'il est la source unique de tous les problèmes. Or, bien souvent, il faut également regarder du côté de la conception fonctionnelle, et même remonter plus en amont encore pour travailler les sujets d'organisation, en lien notamment avec la modularité du produit. Le sujet de la qualité logicielle dépasse donc le cadre de la technique, raison pour laquelle je suis mandaté directement par le CEO . Il faut ensuite prendre les sujets les uns après les autres, accepter que le changement prenne du temps et piloter cet accompagnement main dans la main avec l'entreprise.

Des entreprises me sollicitent spécifiquement sur cette problématique parce que la modularité des systèmes d'information est critique. Bien anticipée, ce sujet ne vous coûtera presque rien, si ce n'est quelques jours de réflexion sur papier. Ignoré, il vous reviendra en boomerang si votre start-up aborde un jour une phase de croissance exponentielle. La question est : y survivra-t-elle ? Une telle situation exige de la méthode et du sang-froid : 1. Établir une cible (cartographier les Bounded Contexts  en partant du métier) ; 2. Établir un chemin de refactoring permettant la coexistence de l'ancien et du nouveau ; 3. Y allouer du temps et refactorer, au fil de l'eau.

J'en fais une catégorie à part entière par souci d'être rigoureux, mais les missions d'audit pur sont en réalité assez rares, l'audit constituant généralement le préalable à un accompagnement de plus long terme. De même que le médecin établit le traitement sur base d'un diagnostic (parfois hypothétique : si le traitement ne fonctionne pas, c'est que le diagnostic n'était pas le bon), l'audit établit un constat partagé par tous et permet d'identifier les premiers axes de travail.

Preuve que la sensibilisation à la dette technique porte ses fruits, des entreprises me contactent depuis peu dès leur création, pour conseiller leurs équipes au moment de poser les fondations techniques du produit (a.k.a. Walking Skeleton ). Cette étape est cruciale pour créer un MVP en minimisant l'accumulation de dette technique, sachant qu'un MVP peut demander beaucoup de travail . Considérez en effet le cas d'un marché mûr tel que la banque en ligne. Si vous voulez tailler des parts de marché à Qonto, votre MVP a intérêt à être vraiment très sérieux. Quoi qu'il en soit, c'est une typologie d'intervention que je souhaite voir se développer sur le long terme, convaincu qu'il vaut mieux prévenir que guérir.

J'ai eu la chance d'enseigner pendant 3 ans chez Hetic, sous la direction de Stéphane Dalbera, alors Directeur des Programmes. Un vrai plaisir et une très belle rencontre. Nous partagions le constat que la plupart des écoles se focalisent à tort sur l'apprentissage des technologies. Ces dernières sont utiles, mais elles sont également hautement périssables : si React tient le haut du pavé aujourd'hui, qu'en sera-t-il dans 10 ans ? Ces architectures auront-elles encore cours ? Mettre l'accent sur les fondamentaux (paradigmes de langage, algorithmie, architectures, méthodologies) me paraît donc bien plus indiqué pour former des professionnels capables de s'adapter à des évolutions que personne ne sait prévoir.

Voici à présent un type de mission singulier : un client, que j'ai accompagné pendant 3 ans, m'avait missionné pour faciliter la montée en compétence de ses équipes, sans sujet précis (en particulier, pas de gros sujet de dette technique). C'était au fond la seule volonté d'emmener chacun un peu plus loin dans sa maîtrise du développement, ce qui dénote déjà une très bonne culture d'entreprise. La mission a pris la forme d'échanges hebdomadaires avec les développeurs, en 1:1, autour d'exercices de mon cru ou de problématiques rencontrées durant leur semaine de travail, les deux étant nécessaires et complémentaires. L'intérêt de ce format est de pouvoir s'adapter très finement aux besoins, aux capacités et aux souhaits de la personne, autrement dit à son rythme propre.

Le savoir est une chose. L'organisation est une chose. Mais parfois, ni l'un ni l'autre ne suffit, car c'est l'humain qu'il faut travailler : amener les personnes à formuler leurs questions, expliciter leurs croyances et les aider à retrouver le chemin de l'action, au travers de l'expérimentation. Ce type d'accompagnement, dans lequel les échanges sont confidentiels, peut débloquer des situations et s'avère particulièrement utile pour les jeunes managers, par exemple les Lead Developers, confrontés à toutes sortes de situations, à leurs yeux inédites.

Chaque mission est en fait une combinaison linéaire de ces différentes typologies. En phase d'avant-vente, les échanges ont pour but de déterminer les modalités les plus pertinentes pour l'organisation qui me sollicite, même si une partie se découvre toujours en cours de route (d'autant plus que les besoins changent avec le temps).