Un seul être vous manque et tout est dépeuplé.
– Lamartine
Introduction
Chez enioka Haute Couture nous réalisons des développements logiciels main dans la main avec les équipes de nos clients. Nous apportons notre savoir-faire en terme de conception applicative et de structurations des activités de développement.
Ainsi, il est assez courant dans notre mode d’intervention de mettre en place une équipe composée d’un Tech Lead expérimenté encadrant à la fois les développeurs du client et des développeurs Haute Couture.
Cette organisation a pour objectif la création d’applications adaptées aux besoins, fiables et dont le client possède la maîtrise. Nous confions les clefs de l’application en fin de mission, sans enfermer nos clients (cf. le manifeste enioka Haute Couture).
Pour ce faire, nous prônons des méthodes de développement qui favorisent la transmission des connaissances par la production de documentations écrites.
Encore un billet de blog où l’auteur se fait mousser ou met un coup de lustrant sur le nom de son entreprise ? En effet, si on croit tout ce qu’on lit sur medium.com, tout le monde fait des tests, tout le monde à une documentation à jour ! Pourtant, nous savons pertinemment que ce n’est pas souvent le cas. Sinon ça se saurait, en tout cas ça se verrait. La plupart du temps, quand un projet est documenté, ce qui n’est pas souvent le cas, nous avons au mieux ça.
Nous avons eu l’occasion d’éprouver, dans la douleur, notre modèle de manière aussi soudaine que violente.
Et « pouf » le Tech Lead
En début d’année 2026, nous réalisons une mission de développement d’une application de gestion de laboratoire pour un de nos clients.
Nous constituons une équipe composée d’un Tech Lead et un développeur enioka Haute Couture accompagné d’un développeur du client. Après quelques ateliers avec le métier, une conception est réalisée, le backlog initié et le projet démarre selon un process agile. Les sprints se succèdent, les fondations de l’application sont en place, le CI/CD permet de tester et déployer l’application dans le premier environnement de test.
Cependant, l’application n’est pas encore totalement définie : il manque des fonctionnalités qui font toujours l’objet d’ateliers avec le métier. Certains points durs sont à résoudre et sont traités de manière itérative.
Arrive le week-end de Pâques, tout le monde part en weekend prolongé, avec la promesse de se retrouver reposés le mardi suivant.
Mais au retour du weekend, catastrophe : le Tech Lead n’est pas revenu.
Un accident est vite arrivé, pas uniquement quand on pratique des activités à risque. Cela peut arriver sur n’importe quel projet, n’importe quand.
Comptez dans votre équipe qui pratique le ski, fait de l’équitation, du bricolage ou simplement prend la voiture ? Multipliez ce nombre par le nombre de membres (bras, jambes) et vous avez une idée des possibilités de juste se faire mal. Dans notre cas, notre Tech Lead pratique tous ces passe-temps et possède encore à ce jour ses quatre membres.
Une journée pour reprendre les rênes
Afin de parer à cette situation exceptionnelle, enioka Haute Couture s’est mobilisé pour proposer un Tech Lead pour reprendre le projet et le mener à bien. Ayant été averti de l’accident durant les congés, le remplacement s’est fait dans la semaine.
Mais le nouveau Tech Lead ne connaît pas le projet, il n’a pas participé aux ateliers de cadrage, et doit pourtant devenir opérationnel rapidement.
Heureusement, de bonnes pratiques documentaires avaient été mises en place dès le début du projet. Le nouveau Tech Lead, comme l’ensemble de l’équipe, a accès à plusieurs niveaux de documentations afin appréhender la complexité de la solution à construire.
Description du projet
C’est le premier niveau d’information, nous avons chez enioka Haute Couture un wiki interne où chaque projet est décrit avec :
- Le sujet de la mission, ses enjeux, son résultat attendu.
- L’identification des acteurs du projet, leurs rôles et les moyens de contact.
- Les canaux de communications.
- Les outils mis à disposition par le client : email, espace documentaire, gestionnaire de tickets, dépôt de code.
- Les points d’entrée de documentation.
Journal de bord
Un journal de bord partagé, en complément de celui tenu par le Tech Lead, permet de connaître l’historique du projet.
Il rappelle les jalons passés et futurs, ainsi que les événements marquants du projet (première livraison, incident…). Nous y consignons également les notes de réunions.
Document d’architecture
Lors des phases de conception, nous réalisons un document d’architecture qui décrit le fonctionnement de l’application et son intégration avec les composants externes ainsi que son organisation interne. C’est le document auquel l’équipe se réfère pour la compréhension de la solution.
Ce document suit le formalisme du modèle C4 pour décrire la solution de la vue la plus générale jusqu’au détail d’implémentation quand cela est nécessaire.
Il contient également d’autres informations, sous la forme de diagrammes :
- Modèle de données.
- Diagramme de déploiement.
- Machine à état des process principaux.
Ce document est ensuite ajusté et complété tout au long du projet afin de refléter la réalité de l’application.
Explications de mécanismes particuliers
En complément du document d’architecture, l’équipe produit des articles expliquant des parties spéciales ou inusuelles dans l’application. Par exemple, le mécanisme d’authentification, un process métier compliqué… Elle explique de manière discursive le fonctionnement d’un composant pour en avoir une compréhension fine.
Sur ce projet, nous avons des articles expliquant la partie authentification, le fonctionnement du fil d’ariane, le mécanisme d’historisation des actions de l’utilisateur.
README
Un document introductif recense toutes les informations nécessaires pour contribuer au projet.
Ce document décrit les dépendances nécessaires, les commandes usuelles (ex : migration de schéma, tests), les règles et convention de nommages en vigueur, etc.
Les pratiques de développement sont soit décrites dans ce document, soit font références à des ressources externes.
Généralement, ce document est présent dans le dépôt de code, conventionnellement nommé « README ».
Il favorise la montée à bord du projet (onboarding), ici le nouveau Tech Lead peut ainsi lancer la solution localement rapidement.
Il est complété par des tutoriels qui expliquent certaines tâches spécifiques.
Tutoriels
Certaines tâches de développement peuvent nécessiter des connaissances qui ne sont pas acquises ou maîtrisées par tous les membres de l’équipe de développement.
Par exemple, comment lancer un environnement complet sur le poste de développement, comment débuger une partie compliquée, comment maintenir une partie du code.
Ces tutoriels sont généralement écrits par toute l’équipe, facilite l’arrivée de nouvelles personnes sur le projet et complètent les éléments déjà automatisés (docker-compose, .editorconfig, etc).
Documentation d’API
La documentation d’API est publiée à partir des balises de documentation des structures du code écrites par les développeurs. C’est la référence au code en production.
Elle est générée avec un outil capable d’extraire les informations depuis le code source (docstring, XmlString, javadoc). Selon les langages, nous avons au choix Doxygen, DocFx, Sphinx…
Elle permet d’explorer la structure de la solution, consulter les valeurs et usage de certaines constantes sans le code. Bien construite, elle peut aussi indiquer comment utiliser les structures et ainsi faciliter l’arrivée d’un nouveau contributeur.
Des tests automatiques
Tout changement vient avec un ou plusieurs tests qui doivent assurer une couverture de code convenable. Les tests permettent de s’assurer que les développement ont été fait selon l’attendu et préviennent des régressions.
Les tests déjà présent formalisent des comportements qui auraient échappés à une description formelle, ou représente des choix pris localement par les développeurs.
Ainsi un contributeur est averti quand ses changements ont cassé une fonctionnalité dont il n’en n’avait pas la connaissance.
CI/CD
La mise en place dès le début du projet de l’automatisation permet exécution des tâches de développement et de publication de l’application de manière simple. Ainsi, l’équipe est capable de packager et déployer l’application juste en pressant un bouton.
L’automatisation de l’exécution systématique des tests, du lint et des analyses statiques de code permet de conserver une qualité prédéfinie de l’application indépendamment des membres de l’équipe.
La publication de la documentation fait également partie d’une étape de la chaine CI/CD.
Dossier d’Exploitation
Le dossier d’exploitation regroupe toutes les informations nécessaires pour faire fonctionner l’application. On reprend le diagramme de déploiement, auquel on va ajouter les noms et adresses des équipements nécessaires (VM, Base de données, etc, ).
Toutes les procédures permettant le maintient en condition opérationnelle sont décrites, étape par étape. Par exemple, le redémarrage, le backup et restauration de la base.
Ce document est par nature un document de transmission de connaissance, car les actions d’administrations sont généralement dévolues aux équipes d’exploitation ou à l’infogérant.
Pour le nouveau Tech Lead, il permet de comprendre comment doit être déployée l’application.
Backlog
Un backlog organisé et maintenu à jour constitue également une part de la documentation éphémère du projet.
Il permet aux membres de l’équipe et au métier de suivre l’avancement du projet et d’avoir une indication sur le reste à faire. Un découpage par domaine fonctionnel permet d’organiser le travail selon les priorités afin d’obtenir les fonctionnalités demandées.
Avant de partir en congés, le Tech Lead initial avait fait du nettoyage (« backlog grooming ») et ainsi préparé le travail à réaliser par l’équipe en retour de ski.
La motivation initiale était de d’alléger sa charge mentale lors du retour de congés, mais il a été bénéfique dans ce cas pour deux raisons supplémentaires :
- pour l’équipe de développement qui a continuée à travailler sur le projet sans interruption,
- pour le Tech Lead remplaçant qui a pu avoir une vision du reste à faire.
Conclusion
Bien sûr, nous ne cassons pas volontairement nos collaborateurs pour tester notre résilience. Pas besoin, ils vont au ski d’eux-même, sans même les encourager.
Dans ce cas, exceptionnel certes, mais pas si rare, la disponibilité de toutes ces sources documentaires a permis d’avoir un remplacement au pied levé.
Pour le Tech Lead remplaçant, il a fallut une bonne journée pour prendre connaissances des éléments les plus importants du projet.
Pour l’équipe, le backlog étant déjà prêt, les développement ont pu continuer pendant le temps de montée en compétence du nouveau Tech Lead.
La multiplicité des formes de documentations, aidée d’éléments d’automatisations et d’une qualité logicielle convenable, a permis de faire une transmission du projet sans drame. Malgré la disparition soudaine de la personne en charge du chantier, il n’y a pas eu de rupture dans la progression du projet.
Ainsi, le projet à continué sans interruption et selon les plans imaginés initialement car les concepts ne sont pas restés sous la forme d’idées nichées dans la tête du seul Tech Lead mais ont été partagés et pérennisés sous la forme écrite. Ce sont les documentations co-construites et diffusées qui apporte la résilience permettant au projet de survivre aux personnes.
Cependant, sa constitution est une tâche ingrate car elle ne peut jamais être complètement exhaustive. Elle doit être complétée par d’autres source d’informations, comme les tests, le backlogs, des scripts, …
Elle est le fruit de l’effort de collaboration de l’équipe par la construction d’un patrimoine de savoir commun.
Notre objectif est toujours de rendre les clefs, pour cela la documentation est nécessaire mais pas suffisante. Le soin apporté à la construction d’une application, par une conception rigoureuse et du code clairement organisé, contribue également à la qualité de la solution et aussi à la facilité de sa transmission.
Ainsi, la mise en place de pratiques de développement basées sur la collaboration et le diffusion de savoir nous met en capacité de transmettre le patrimoine applicatif à tout moment, en fin de projet ou en cas d’accident de ski.
