Développeur Java/Angular à la Société Générale, Maxime est, ce qu’on appelle dans le jargon informatique, un software Craftsman.
Son quotidien : la recherche de l’équilibre entre des besoins utilisateurs et un code de qualité. Exigence, culture de l’artisanat logiciel, dans une société où le logiciel devient omniprésent, atteindre un haut niveau de qualité devient un enjeu stratégique. Entretien.
On appelle communément Craftsman, un développeur convaincu par les valeurs d’un mouvement. Quels sont les axes du manifeste qui vous ont convaincu ?
Le Manifeste est, selon moi, un prérequis à l’agilité. Le Manifeste Agile parle de gérer et d’accepter le changement, ce à quoi le Manifeste du Software Craftsmanship répond en précisant qu’il faut sans cesse ajouter de la valeur à un programme. Chaque ligne de code doit créer de la valeur, elle ne doit pas coûter. Le manifeste regroupe des initiatives qui permettent aux équipes techniques de proposer des solutions pérennes, en adéquation aux problématiques client. Ainsi, le principe de « bien conçu » signifie, une solution bien conçue techniquement, susceptible d’évoluer rapidement. C’est donc, dans l’idéal, un produit dont on ne va pas réécrire le code dans 5 ans. Si j’adhère aux principes du Manifeste du Software Craftsmanship, c’est qu’avant tout, les valeurs énoncées correspondent à mon exigence du travail bien fait.
Quelle est la mission d’un Craftsman ?
La mission d’un software Craftsman, c’est, avant toute chose, ramener au centre du développement informatique l’essence ou la nature de ce pourquoi à un moment M, on décide de développer un produit, un service ou une application. Il est impératif que le produit réalisé ne soit pas un poste de dépense, mais d’investissement pour les clients.
Investir dans un Craftsman, c’est investir dans un outil bien « designé », susceptible de répondre aux besoins réels des utilisateurs, qu’il soit porteur de solutions à des problématiques identifiées.
Dans la réalité, assez souvent, on nous demande de développer une solution mais pas de résoudre un problème. Ce qui n’est pas viable, sur le moyen terme, puisqu’à aucun moment du développement, on répond de manière intelligente et technique aux besoins utilisateurs.
Être Craftsman c’est donc agir par itération, être capable de comprendre un problème et le résoudre. Mais aussi chercher et trouver des axes d’amélioration sur l’outil. Avec pour objectif final, la satisfaction utilisateur que ce soit pour lui faire gagner du temps ou en nouvelles fonctionnalités.
Le software Craftsman est considéré comme un artisan du code, pourquoi cette notion d’artisanat est-elle mise en avant ?
La métaphore avec l’artisan et l’artisanat est très appropriée. En effet, cette dénomination recouvre plusieurs notions. Celle d’un technicien avec une expérience certaine, un spécialiste qu’on consulte pour qu’il nous prodigue les bons conseils, un professionnel qui sait répondre à une problématique. Notre expérience, notre histoire, notre vision d’artisan du code permet d’être force de proposition, créatrice de valeur. Par ailleurs, un artisan doit être à l’écoute du monde qui l’entoure pour alimenter son savoir et son savoir-faire. Et dans ce cadre, les communautés de Craftsmen ont un double avantage : celui de faire grandir les métiers et de diffuser la connaissance de nouveaux outils. Sans ces échanges, on perd en efficience, en rapidité, en qualité mais surtout en innovation.
On fait souvent la différence entre un développeur et un Craftsman, qu’est-ce qui différencie les Crafts des autres développeurs ?
Pour moi, Craftsman n’est pas une fonction mais plutôt un état d’esprit dont le leitmotiv est l’amélioration continue, l’apprentissage au long cours. Toutefois, certains développeurs n’évoluent pas dans un environnement propice à la diffusion de la connaissance tandis que d’autres n’ont aucune envie de s’ouvrir à ce qui les entoure.
Certains développeurs sont donc des opérationnels qui se contentent de faire ce qu’on leur demande, alors que d’autres tentent d’aller plus loin, de faire avancer les choses. In fine, la différence entre un développeur et un Craftsman ne se situe que dans la capacité de chacun à être curieux et à vouloir faire avancer les choses.
Justement est-ce que l’interaction collaborateur / utilisateur est un vrai facteur de création de valeur ?
Oui, l’interaction est créatrice de valeur. Mais pour créer de la valeur, il est nécessaire de se départir du schéma classique de développement où le développeur est cantonné dans un rôle de simple exécutant. Dans ce contexte, il se retrouve à développer un produit dont la liste des fonctionnalités inutiles est sans fin, génératrice de bugs et de perte de temps !
L’intérêt de consulter en amont l’équipe technique, c’est offrir à l’utilisateur la possibilité d’entrevoir de nouvelles solutions, d’être sûr que son besoin va être entendu et être transformé en fonctionnalité. Certes, ce sera peut-être moins spectaculaire que ce que l’utilisateur pouvait imaginer mais techniquement ça fonctionnera.
D’autant plus que cette flexibilité nous donne le droit à l’échec et de recommencer très vite pour arriver à la satisfaction ultime. In fine, on itère, on teste, mon produit reste vivant et le contrat d’innovation est rempli.
Pourquoi est-il si important d’améliorer la qualité du code ?
C’est une notion simple à comprendre mais difficile à mesurer. Quand on réfléchit qualité, en terme logiciel on pense souvent bug ou rapidité. Or, quand on parle qualité du code, la seule question à se poser c’est, comment peut-on faire évoluer le code facilement ? Est ce qu’on comprend ce que fait le code ? Un code de qualité c’est donc un code simple, lisible, intelligible et expressif que l’on modifie au fur et à mesure et auquel on peut rapidement ajouter de nouvelles fonctionnalités.
Rendre lisible le code, c’est à chaque étape d’écriture, se poser la même question, à savoir, si je lis ce code pour la première fois, quelle est la meilleure manière de l’écrire pour que je le comprenne vite ? Un bon code est donc un code que l’on retravaille facilement. Pour obtenir un tel résultat il faut refactorer souvent pour que le design s’approche le plus possible du métier. Et le prérequis au refactoring (réécriture) ce sont les tests automatisés. Ils nous permettent de savoir si l’on n’a pas cassé de fonctionnalités.
Quels sont les dangers de la non-qualité du code ?
En perdant confiance en notre capacité de faire évoluer le code, on instaure un cercle vicieux. En effet, pour améliorer le code, on rajoute du code, des bugs, des tests et donc du temps de développement. Outre de perdre confiance en nos capacités, on perd la confiance des utilisateurs. On appelle ça, la dette technique ou code legacy, c’est-à-dire un code hermétique, qu’on ne comprend plus et qu’on ne peut pas tester.
Ce phénomène peut arriver très vite, et pour l’empêcher, il est impératif que tous les membres de l’équipe aient à cœur de produire le meilleur logiciel possible et mettent en place les pratiques nécessaires : tests, revues de code, pair programming, …
C’est la force d’une équipe : on partage nos connaissances, on apprend les uns des autres, on grandit ensemble. C’est le principe même de l’agilité et de la collaboration.
L’absence de la culture de qualité serait à l’origine des 20% de turnover moyen du secteur informatique, votre sentiment ?
Je ne pense pas que ce soit l’absence d’une culture de la qualité qui soit à l’origine du turn-over. C’est plutôt la façon dont sont considérés les développeurs au sein d’une organisation qui est en cause. Aujourd’hui, ils sont encore perçus comme de simples exécutants et non comme des collaborateurs susceptibles d’apporter des solutions, d’être consultés.
Souvent on leur demande d’aller plus vite, on les rend responsables des bugs, de la mauvaise qualité tout en ignorant leurs avis et leurs propositions. C’est tout l’héritage des projets en cycle V dont nous pâtissons, de ces projets dans lesquels les étapes s’enchaînent sans que les parties prenantes soient consultées. On doit reconsidérer le rôle de développeur, lui redonner de l’autonomie, lui faire confiance, le responsabiliser, l’impliquer dans la vie du projet, le nourrir et lui donner la possibilité de nourrir les autres.
Une formation peut-elle suffire à devenir Craftsman ?
Est-ce qu’une formation peut permettre à quelqu’un de devenir généreux ? Je ne crois pas. On peut être Craftsman et jeune diplômé comme on peut avoir 10 ans d’expérience et être insensible au manifeste. Le software Craftsmanship est un état d’esprit, une envie.
Celle d’aller plus loin, de pousser ses limites. A contrario, une formation peut engendrer des vocations mais c’est de la sensibilité d’un développeur dont il est surtout question et de son appétence à aller chercher la nouveauté et la perfectibilité. Les formations sont néanmoins très utiles pour diffuser les pratiques et enseigner les méthodes.
Mais souvent insuffisante pour l’application au quotidien et le recours à un coach est souvent un bon complément.
Que pensez-vous des coach Craft ?
Je n’ai pas vraiment eu l’occasion de travailler avec des coachs. Mais à mon sens, ce qui est important, c’est qu’un coach soit présent au quotidien avec les équipes plutôt que faire des ateliers ponctuels. Pour que les gens acceptent l’effort de faire de nouvelles choses, il faut que les personnes qui les encadrent leur disent « venez avec moi on va faire ça ensemble se sera plus simple » plutôt que de dire « vous devriez faire comme ça » puis partir.
La plus-value d’un coach c’est d’être immergé au sein des équipes, sur un temps long, de leur montrer que le chemin n’est pas si dur, et de leur apprendre à surmonter les obstacles. L’avantage du coach est aussi son statut d’expert, qui lui permettra de dialoguer avec le management, qui ne comprend pas toujours qu’il devrait accompagner les équipes techniques dans leur montée en compétences, plutôt que les pousser à livrer toujours plus vite.
Comment faire entrer les valeurs du Craftsmanship dans l’entreprise afin qu’elles deviennent le standard et non l’exception ?
Tout dépend de comment est considéré l’informatique dans l’entreprise. Est-ce un mal nécessaire, une richesse ? Tout part de là. Le développement doit être vu comme un levier stratégique, les équipes techniques comme des partenaires pouvant proposer des solutions innovantes.
Quelles sont les actions à mener au sein de l’entreprise pour promouvoir une culture de la qualité et de l’apprentissage permanent ?
Il faut être conscient du champ des possibles, être ouvert, expérimenter, faire confiance aux équipes techniques pour qu’elles essaient des solutions, qu’elles soient responsabilisées plutôt qu’elles subissent, qu’on leur accorde le droit à l’échec… Ainsi, il est essentiel d’arrêter de donner des listes de courses aux développeurs, il faut que les Métiers arrêtent d’être traumatisés par les projets informatiques. Introduire de l’agilité à tous les points de contact de la chaîne de production devient donc primordial.
En prenant conscience que chaque collaborateur travaille pour une même communauté qui s’appelle l’entreprise, on met en place une politique de direction plutôt que de directives. C’est dans ce sens que le changement doit s’opérer au sein des organisations.
Aujourd’hui, en France, le problème est qu’il n’y a pas de reconnaissance pour les bons techniciens (financier, statut…). Est-ce que le seul avenir d’un bon développeur est de devenir manager ? Le Craftsmanship ne peut-il pas ouvrir la voie à de nouvelles politiques RH ?
Aujourd’hui, il n’existe pas vraiment de fiche de poste pour les profils techniques expérimentés. Le management et les équipes RH n’ont pas réellement compris que devenir manager n’était pas forcément le graal du développeur.
Il faut plancher sur des fiches de poste de leader technique, de coach interne, d’experts, car il serait plus rentable pour une entreprise d’avoir de bons développeurs plutôt que de mauvais managers. Il faut aussi comprendre que les techniciens souhaitent continuer à apprendre et voir de nouvelles choses et donc favoriser les mobilités internes.
