La qualité 360 : des principes, des indicateurs… mais en vrai ça ressemble à quoi ?
💡 Cet article a été publié dans le cadre notre série “Product & Tech” qui vous propose de naviguer avec nos experts dans la complexité de la conception de vos produits stratégiques en 2025. Dans les épisodes précédents : adoptez la philosophie “Start with why”, développez des équipes pluridisciplinaires et passionnées. Pour ne pas rater les prochains épisodes, abonnez-vous à notre newsletter !
La qualité 360, c’est notre envie de poser un regard large sur cette question obsédante : comment définir le juste niveau d’effort à mettre sur la qualité, ni trop, ni trop peu ?
Comme vous le savez, il n’y a pas de réponse clé en main, d’outil magique, de solution miracle, de formation transformante… Il y a des femmes et des hommes qui œuvrent au quotidien et cherchent le meilleur compromis de qualité avec les moyens qu’ils ont à leur portée.
Pourtant, de notre expérience, il existe quelques signes extérieurs de qualité qui en général sont des bons signes.
[TL;DR] Si vous n’avez pas envie de lire tout l’article, voici une liste non-exhaustive de signes extérieurs de qualité, attention c’est brut :
- Aujourd’hui un développeur s’est exclamé à voix haute dans l’open-space : “quand je vois ce code, je comprends ce que veut dire qualité !”
- Développeurs et Product Managers parlent d’évolutivité du produit et de dette technique consciente ou inconsciente à intervalles réguliers
- Le métier est ravi que vous déployiez fréquemment en production. Cela le challenge positivement sur le compromis à trouver entre TTM et complexité d’évolution, et lui permet de valider rapidement l’impact
- Vous connaissez, votre entreprise connaît, le CEO connaît : le TOIL ! et tous les jours, les développeurs dans le cadre d’une stratégie continue de modernisation technique réduisent le TOIL
- Dans mon entreprise, il y a des contributeurs individuels, des gens en transverse qui codent et agissent pour la qualité sans imputer sur une ligne projet
- Votre entreprise sait proposer à ses développeurs une échelle de carrière apte à valoriser l’expertise technique sans éloigner du code
- Les ingénieurs entendent parler de stratégie et le CEO entend parler de code
- Les ingénieurs ne prennent pas pour argent comptant tout ce que la GEN AI leur propose
- Votre entreprise développe ses propres outils pour manager la qualité !
- La qualité est affaire de pro-activité
- Et plus encore…
Signe extérieur de qualité : “Quand je vois ce code, je comprends ce que veut dire qualité !” avait-il dit.
Quand je suis arrivé chez OCTO, en 2015, j’ai croisé un développeur qui s'enthousiasmait de la quantité et de la qualité des tests unitaires (faits par d’autres Octos) tout juste découverts sur une application dont il venait de prendre la charge.
La qualité, vue de sa fenêtre, était tout autant la facilité qu’il avait de monter sur le sujet, de comprendre les règles métiers, que le filet de sécurité offert par ces nombreux tests.
Ce développeur, c’est Adrien Saunier, ASA, dans le langage polygrammique d’OCTO. Aujourd’hui il est référent SRE, en pointe sur la fiabilité (une autre facette de la qualité) des systèmes informatiques : https://blog.octo.com/en-cas-d'urgence-brisez-la-glace--generic-mitigations-et-gestion-d'incident
Le “red button” qui permet de réagir sereinement quand une panne inconnue survient dans notre SI. Et vous ? vous en avez un ?
Signe extérieur de qualité : Développeurs et Product Managers parlent d’évolutivité du produit et de dette technique consciente ou inconsciente à intervalles réguliers.
En 1970, Winston Royce, un informaticien américain, que l’on dirait tout droit sorti des messages à caractères informatifs (vous ne connaissez pas ? vous devriez…), a écrit un magnifique et inspirant article sur l’impossibilité qu’un système informatique, créé dans une logique frame/build/test/run, puisse être de bonne qualité.
2025 - 1970 = 55 ans. C’est vieux et pourtant terriblement toujours d’actualité.
Winston Royce nous apprend que la qualité n’est pas le résultat d’un processus prédictible et répétable mais de quelque chose d’autre qui mélange des boucles de feedbacks et des intéractions multiples. Sans vraiment mettre le doigt sur l’agilité (nous sommes en 1970 et scrum prend ses sources au début des années 1990), Winston Royce imagine des pistes où le logiciel prend sa forme définitive grâce à des réécritures successives de l’architecture et du code.
Cette idée des feedbacks répétés est aujourd’hui une constante dans la littérature et la pratique, le but est d’éprouver rapidement la technologie mais aussi le fonctionnel et l’impact.
Mettre en production rapidement : constante dans la littérature et pourtant toujours un débat dans les entreprises ! Car en vrai, pourquoi mettre en production plus fréquemment que le besoin métier ne le justifie ? C’est du temps perdu ! non ?
Signe extérieur de qualité : Le métier est ravi que vous déployiez fréquemment en production. Cela le challenge positivement sur le compromis à trouver entre TTM et complexité d’évolution, et lui permet de valider rapidement l’impact
Le temps perdu c’est mal.
Au fait, perdu pour qui ? Pour le business me direz-vous, pour celui qui attend désespérément son évolution pendant que vous vous amusez à déployer des trucs qui ne servent à rien tous les 20 jours, qu’il pleuve, vente ou neige !
C’est une bonne remarque et nous n’avons rien à répondre à ça. Ah si ! En 2012, Benoît Lafontaine le CTO d’OCTO a écrit un article sur le sujet du déploiement continu :
2025 - 2012 = 13 ans. C’est pas si vieux, mais quand même, et puis ce n’est pas vraiment une réponse.
Quand on ne sait pas répondre à une question, le plus sage est d’aller dans un monde où cette question ne se pose plus !
Bon admettons, déployer fréquemment c’est bien. Et c’est vrai tout le monde (les éditeurs) le fait. Nos smartphones, nos voitures, le climatiseur, la cafetière, passent leur temps à se mettre à jour, mais quand même ça doit être compliqué et long, non ?
Signe extérieur de qualité : vous connaissez, votre entreprise connaît, le CEO connaît : le TOIL !
Oui, les ingénieurs perdent un temps considérable dans des activités chronophage qui leur font perdre du temps, alors ils ont inventé un mot pour ça : le TOIL (prononcer /tɔɪl/, avec /ɔɪ/ comme dans boy ou noise).
C’est quoi le TOIL ?
C’est le mot bizarre qui décrit l’une de ces deux situations :
1. Relancer à la main le pipeline de CICD qui a planté pour on ne sait quelle raison (pas cool)
2. Automatiser le réentraînement d’un modèle de Machine Learning à chaque dépôt d’un nouveau fichier (cool)
Si vous avez répondu 1. Vous devez interrompre immédiatement la lecture de cet article et nous contacter de toute urgence.
Ouf, si vous êtes encore là, c’est que vous avez su répondre. Mais vous vous dites : et donc ?
Signe extérieur de qualité : tous les jours, les développeurs dans le cadre d’une stratégie continue de modernisation technique réduisent le TOIL
Puisque vous savez que le TOIL décrit ce travail répétitif et pénible qui gâche le quotidien des ingénieurs, regardez plutôt cette vidéo : "La paralysie des équipes ML en run" par Aurélien Massiot, ML Engineer
Le TOIL est là, on ne peut pas l’éliminer complètement mais si on ne fait rien pour lutter, c’est lui qui va nous éliminer - faites comme nous, utilisez TOIL 2000
Je n’achète pas ce signe extérieur, comment voir et savoir que les développeurs réduisent le TOIL ? encore un truc de post-it ?
Vous avez raison d’être pointilleux, réduire le TOIL est un sujet transverse à toute l’organisation technique et qu’est-ce qui pourrait donc bien pousser un développeur à faire quelque chose qui n’impacte pas directement, ou pas seulement, l’équipe dans laquelle il travaille ?
Un coach ? mouais, je vous vois venir OCTO… Un développeur plus cher que la moyenne ? vous êtes vraiment pas discret, OCTO, vu ! … alors quoi ?
Signe extérieur de qualité : dans mon entreprise, il y a des contributeurs individuels, des gens en transverse qui codent et agissent pour la qualité sans imputer sur une ligne projet
Frédéric Lenci d’Octo a préparé une table ronde sur ce sujet de la contribution individuelle dans lequel on retrouve des “coding architect” ou des “référents transverses”, des personnes qui œuvrent au plus près des équipes pour améliorer la qualité et standardiser ce qui doit l’être.
Voici quelques verbatims qui ressortent de la discussion.
“Être en proximité des équipes, suivre le code, pousser des pratiques et être là pour apporter des solutions concrètes et pragmatiques”...”il faut pouvoir mettre les mains dedans”
“C’est un enjeu de temps. Il faut avoir le temps, avoir le rôle et l’étiquette et être présentée en tant que tel. C’est hyper important”
“Au début, beaucoup d'investissement sur la définition des standards, les documenter, avoir une hygiène de commit propre, documenter énormément de choses et faire en sorte que cela soit respecté de façon automatique ou par la revue de code”...”Il faut qu’il y ait le plus possible une forme de standardisation”
“Il faut de l’oral ET de l’écrit. L'écrit seul ne marche pas, l’oral non plus mais associer les deux fonctionne bien”
“Un code qui n’est plus livré régulièrement en production est un code sur lequel on perd la main et qui est en train de mourir”...”Il y a l’enjeu de faire vivre la base de code et de mettre les outils et les pratiques pour le faire”
“Veiller à ne pas glisser vers le code pour se faire plaisir, il faut garder une bonne frugalité technique et fonctionnelle pour avoir du code maintenable et évolutif. La frugalité c’est un outil de qualité de code”
“Centraliser et versionner le code, c’est le nerf de la guerre, s’assurer qu’on livre bien ce qu’on a codé et pas quelque chose de mal fusionné avec le code du voisin. C’est hyper important”
“Je suis les merge request, celles qui sont ouvertes sur la période, combien sont ouvertes, fermées, la durée de vie des branches, c'est hyper important.”
“AMET : une équipe dédiée à résorber de la dette et/ou améliorer les pratiques. Ca vient de Nick Tune (ou team topology) c’est une équipe dédiée à l’amélioration et au maintien du code.”
Les contributeurs individuels qui nous parlent ici sont des ingénieurs senior avec la capacité d’influencer leurs collègues sans en passer par l’autoritarisme. Cette légitimité, ils la tirent de leur expérience et de la reconnaissance que l’entreprise leur a donné avec le temps.
Expérience + reconnaissance = carrière
Signe extérieur de qualité : votre entreprise sait proposer à ses développeurs une échelle de carrière apte à valoriser l’expertise technique sans éloigner du code
Le premier gain réside dans votre capacité à proposer des échelles de carrières à vos développeurs (internes) les plus expérimentés. Vous pourriez nous répondre : je n’ai pas de développeurs internes.
Mais honnêtement, se lancer comme vous le faites dans la digitalisation de votre activité à grand renfort d’IA que ce soit en Make ou en Buy sans à un moment songer à internaliser des compétences expertes pour dénouer toute la complexité de ce qui va se dérouler sous vos pieds nous paraît aussi risqué que de chercher à lire cette phrase sans respirer.
Deuxième bénéfice, l’employabilité interne ou la facilité pour vos ingénieurs de bouger d’une équipe à l’autre, et d’y retrouver une grande partie de ce qu’ils ont connu dans l’équipe d’avant.
On pourrait appeler ça “la culture technique de votre entreprise”.
Signe extérieur de NON qualité : cette semaine, chez vous, quelqu’un a pensé “je dois réaliser une tâche, je pourrais demander de l’aide à quelqu’un qui l’a déjà fait mais il est dans une autre équipe, il n’aura pas le temps de m’aider, et si je réinventais la roue, je serais génial, et ma nouvelle roue serait meilleure que l’autre”, ou pas !
L'employabilité interne est un bénéfice car elle permet d’augmenter votre capacité à former la bonne équipe d’expert au bon moment et pour le bon besoin et de s’assurer que chacun est à la meilleure place, donne le maximum de lui-même, et s’épanouit de façon optimale (phrase générée par une IA pour gagner du temps lors de l’écriture de l'article).
Vous avez le sentiment que nous nous éloignons de notre sujet de qualité ? Et si les défauts de qualité venaient aussi du fait que parfois, on n’a juste pas la bonne personne au bon endroit au bon moment ?
Admettons que vous achetiez ce concept “de sachant technique proche du code en transverse”, je ne vois pas du tout comment ça pourrait marcher, c’est un truc genre tech authority tour d’ivoire que vous nous racontez là.
Non.
Signe extérieur de qualité 360 : les ingénieurs entendent parler de stratégie et le CEO entend parler de code
De sa position d’advisor transverse, Matthieu nous explique qu’il apporte du support sur les bonnes pratiques et au final des standards qui structurent la qualité globale de tous. De sa position il capte des informations sur la qualité qu’il remonte à sa hiérarchie (bottom-up) et partage des informations sur la stratégie qu’il diffuse aux équipes (top-down).
Signe extérieur de qualité 360 (valable en 2025) : les ingénieurs ne prennent pas pour argent comptant tout ce que la GEN AI leur propose
Tout cela est bien gentil mais l’IA va tout régler d’un coup d’un seul et très vite !
Nicolas Laurent peut coder une application tout seul en 30 minutes : Coder une application inconnue en 30 min grâce à l’IA : buzz ou révolution ? - Nicolas Laurent
Promis, nous dépublierons cet article dès que l’IA pourra faire tout ce qui est dans cette page sans l'assistance d’un humain; en attendant, puisque vous êtes là, lisez la fin !
En parlant d’IA, si les cordonniers avaient utilisé un peu de leur temps à inventer un robot-semelage augmenté à l’IA, ils auraient eu le même impact sur le monde des pieds et se seraient bien chaussés, fin de l’adage.
Tellement simple, ça fait réfléchir : fabriquer un outil (le robot) pour aider à mieux fabriquer des outils (les chaussures).
Un exemple d’outil, comme ça, que l’on peut se développer pour augmenter la qualité de son système ?
Construire la carte d'un SI en mouvement pour visualiser l'efficience - La Duck Conf 2024
Signe extérieur de qualité : la qualité c’est le problème quotidien de quelques uns
A ce stade, nous vous repartissons en deux groupes de lecteurs :
- ceux qui étaient déjà convaincu,
- ceux qui ne sont toujours pas convaincus parce que chez vous, c’est pas pareil.
Le groupe 2, vous avez raison de douter, car la qualité est le résultat d’un compromis entre les exigences, le temps, et les compétences, auquel il est difficile d’apporter des recettes toutes faites sans contexte.
Il n’y a pas de solutions magiques, il y a des personnes qui œuvrent au quotidien dans le sens de la qualité car produire un service fiable et évolutif est leur raison d’être.
Ces personnes peuvent être :
- réactives : le super-héros qui sauve le SI quand il plante ou le projet quand il va dans le mur,
- pro-actives : l’influenceur qui donne les moyens à tous de faire un travail de qualité.
Ces personnes pro-actives ont un métier et bonne nouvelle ce métier a un nom, il se nomme Staff Engineer, et c’est celui de beaucoup de mes collègues d’OCTO !
