Depuis juin 2025, j’ai la chance de travailler chez Agicap, éditeur d’une solution SaaS de gestion de trésorerie d’entreprise. Le but était de monter une petite équipe qui travaillerait pendant 1 an (ou plus) au développement d’un module de gestion de risque de change. En gros, lorsqu’une entreprise a des filiales ou des clients à l’étranger, elle va faire face à des risques liés aux taux de change : si elle achète 10 millions de $ de matières premières et qu’elle revend le produit fini à une clientèle européenne en €, ses prévisions budgétaires seront soumises aux variations du change EUR/USD, ce qui ajoute de l’incertitude.
L’équipe
L’équipe se compose de 6 personnes qui travaillent en direct au quotidien :
- Le Product Manager, qui maîtrise toute la partie métier, gère les priorités, la communication avec les clients et les équipes de support ;
- Le Tech Lead, qui nous guide (avec bienveillance !) sur la partie technique et notamment les interactions avec l’infrastructure et les autres équipes, et qui fait aussi du dev ;
- La Product Designer, responsable de l’UI/UX du module, de son intégration dans le design system ;
- Les 3 devs, 2 côté back et 1 front (même si à titre personnel j’ai switché pas mal sur la partie front de janvier à mai 2026), en plus du tech lead. Séniorité allant de 12 à 25 ans d’expérience.
À cela, on peut adjoindre des personnes avec qui on va interagir fréquemment comme notre manager ou le SRE dédié à notre projet. On est donc sur une taille d’équipe très raisonnable.
Organisation
Nous travaillons toustes à distance à temps plein et à l’exception de 2 venues sur Lyon (siège d’Agicap) et un séjour de 3 jours dans le Vexin, nous ne travaillons jamais en présentiel. L’utilisation de la visio est donc prépondérante, on y reviendra plus bas.
Dès le départ, au vu de nos profils et de la philosophie d’Agicap, nous nous sommes aligné·es sur les pratiques mises en avant par Accelerate.
Méthodologie Kanban
C’est quoi ?
On évacue rapidement le premier sujet : pas de Scrum. Une fois qu’on a réalisé que Scrum est essentiellement une succession de petits cycles en V avec des contraintes artificielles qui posent souvent plus de problèmes qu’elles n’en résolvent, on peut commencer à envisager sereinement le passage au Kanban.
Chez nous pas de sprint, pas de démo à date fixe, et surtout pas d’estimation. Tout est drivé par le métier et nos discussions fréquentes (voir section suivante) donnent de la visibilité à chaque instant, rendant superflue toute procédure visant à forcer la remontée d’information. En bref, quand on discute sereinement et régulièrement avec les parties prenantes, pas besoin d’estimations ou de planning.
On fait tout de même des rétrospectives tous les mois afin de prendre un peu de recul sur nos pratiques et mettre en place les actions adéquates.
Pourquoi c’est bien ?
Scrum (ou en tout cas la version que l’on croise le plus souvent) est très balisé, souffre de rituels à l’intérêt discutable et fabrique des contraintes artificielles (sprints) et rigides (contenu des sprints). C’est un vaste sujet auquel je dédierai probablement un article. À l’inverse, Kanban se focalise vraiment sur la visibilité des travaux en cours et à venir tout en favorisant un rythme soutenable sans pression. Bref, un mode flux orienté produit plutôt qu’une gestion de projet IT.
Proximité entre tech et produit
C’est quoi ?
On ne veut pas de silo mais au contraire favoriser au maximum la transparence ; il faut savoir vulgariser, communiquer et ne pas s’éparpiller dans des détails trop complexes.
Il est crucial que les développeur·ses comprennent ce qu’on leur demande : ce qui est livré en production ce n’est pas une spec ou un ticket, c’est la compréhension des devs.
Concrètement, ça se traduit par des réunions ou des points très réguliers, venant notamment de la part du PM. Par exemple, au tout début, il a introduit les Hedge Clubs, des mini formations quasi-quotidiennes sur le coeur de métier de la gestion du risque de change.
S’ajoutent à cela des refinements au fil de l’eau pour chaque feature. En gros, juste après le point quotidien du matin, on dédie 1h à présenter puis discuter d’une fonctionnalité qui va rapidement arriver dans notre flux. C’est dans ce genre de point qu’on prend d’une part la connaissance au niveau de la terminologie et du workflow métier, mais aussi de l’UI/UX via des maquettes. Ensuite, on pose pas mal de questions, soit pour éclaircir des incompréhensions et lever des implicites, soit pour challenger sur des cas à la marge. C’est très riche, très dense et régulier (2 à 4 fois par semaine).
D’autre part, le produit et le design restent ultra accessibles tout le temps hors contraintes type réunions ou entretiens clients. Cela permet des retours très rapides à nos questions quand, côté tech, on est en plein développement ou phase de réflexion. Là encore, le but est d’éviter les implicites que l’on pourrait ensuite retrouver dans le code. Cela demande à la fois de l’humilité et de la patience de tous les côtés.
Pourquoi c’est bien ?
Faire discuter des gens lors d’un projet, c’est forcément bien 🙂 Sans vouloir enfoncer trop de portes ouvertes, il est crucial que les développeur·ses comprennent ce qu’on leur demande : ce qui est livré en production ce n’est pas une spec ou un ticket, c’est la compréhension des devs. Imaginez que vous vouliez refaire votre salle de bain : vous préfèreriez passer un peu de temps avec l’artisan pour lui expliquer ce que vous souhaitez et échanger sur le sujet, ou lui donner un document de 8 pages détaillant tout point par point et le laisser se débrouiller pendant 3 semaines ?
Pair et mob programming à temps plein
C’est quoi ?
Dans la série « tout le monde en parle mais peu de monde le fait » alors que c’est pourtant un élément central de la livraison continue, voici le pair et le mob programming. L’idée, qui a été populariśee par le mouvement d’eXtreme Programming (XP), est que 2 développeur·ses ou plus travaillent en même temps sur le même écran pour une même fonctionnalité ou user story.
Côté back, comme on était 3, on a opté pour ce mode. À mon avis c’est très important au début, d’une part parce que l’équipe est jeune et que cela permet d’adopter des conventions communes de facto et d’apprendre à se connaître, mais aussi tout simplement parce que tout le monde acquiert le même niveau de connaissance autour du métier, des fonctionnalités et des diverses couches techniques de la base de code. Ensuite, pas besoin de revue asynchrone de pull request, sujet chronophage et bloquant (outre ses autres défauts dont on ne parlera pas aujourd’hui).
Et donc on fait ça pour toutes les tâches de développement.
Toute la journée ???
On ne va pas se mentir : passer toute une journée puis toute une semaine en mob programming est très énergivore. Il est donc crucial d’aménager des temps de pause et de ne pas faire des journées à rallonge sous peine d’épuisement.
« Tout seul on va plus vite, ensemble on va plus loin ».
Il faut aussi savoir communiquer et sortir de sa zone de confort, car il faut faire des compromis en permanence. Cela va des conventions de code (« on fait des if ou des ternaires ? On indente comme ci ou comme ça ? ») à l’architecture (CQRS ? Onion ? Hexa ? A-t-on d’ailleurs les mêmes définitions ?), en passant par la taille des incréments ou l’écriture de tests. Les personnalités inflexibles ne pourront pas s’adapter facilement.
Au niveau des outils, c’est assez simple : visio, partage d’écran et mob.sh. On ne fait pas de time boxing, ce qui peut parfois conduire à des dérives, mais ne nous a jamais réellement posé de problème au quotidien.
Pourquoi c’est bien ?
« Tout seul on va plus vite, ensemble on va plus loin ». À plusieurs, on va prendre le temps nécessaire pour que l’implémentation soit correcte, parlante et complète. La validation est ensuite instantanée, pas besoin de demander à quelqu’un d’extérieur qui n’a pas participé de valider a posteriori le travail effectué.
Code simple
Comment ça ?
Une tendance qui me sidère actuellement est la complexité accidentelle que l’on retrouve dans beaucoup de bases de code en .Net. MediatR, EF Core, interfaces à tire-larigot, j’en passe et des meilleures. La plupart du temps, ces abstractions sont inutiles et leur utilisation relève souvent du dogme.
On a donc pris le parti de faire au plus simple. Les patterns techniques inutiles, la surabondance de couches techniques, les découplages bidons introduits par une dépendance non pertinente, etc… sont autant de freins à la compréhension et donc à l’ajout de valeur dans notre produit. Notre séniorité doit nous permettre de nous affranchir de cette complexité accidentelle. On va donc à l’essentiel tout en préservant l’intégrité des règles métier pour ne pas la polluer avec des considérations techniques.
Pourquoi c’est bien ?
Pour chaque dépendance technique qu’on ajoute, pour chaque dogme qu’on suit, il faut se poser la question de son bien-fondé. Apporte-t-on une réelle valeur au produit ? Répond-on à un vrai problème ? Si la réponse est négative ou incertaine, alors favorisons une approche plus simple. Il y a de bonnes chances qu’on n’ait pas besoin de la complexité technique que l’on s’apprêtait à ajouter.
Tests « gros grain » automatisés
C’est quoi ?
J’ai déja parlé dans d’autres articles d’une technique de test permettant de tester une API en la lançant carrément plutôt que de tester unitairement chaque bloc. Et donc dépasser le concept de pyramide de tests pour favoriser une approche en losange ou en « diamant » (peu de tests unitaires et plus de tests d’acceptance).
Nous avons poussé le curseur un peu plus loin : non seulement nous lançons l’API en mémoire à chaque test mais en plus une base de données dédiée est montée avec le schéma et les données nécessaires au test grâce à Testcontainers. Seuls les appels HTTP externes sont simulés avec NSubstitute. Ça peut paraître lourd et coûteux de prime abord mais c’est un gain énorme en termes de confiance et de non-régression.
De plus, travaillant en TDD, faire des tests de ce type nous permet de nous poser la question du contexte du scénario en tout point : initialisation des données, paramètres nécessaires en entrée, et format et données en sortie.
Notre projet actuel contient environ 500 tests de ce type. Résultat : 2 bugs (dont 0 régression) en prod en 9 mois. Par comparaison, nous avons dû intervenir sur une base de code legacy comprenant 980+ tests unitaires et 0 test « gros grain » : pour 1 dev, on a introduit une grosse régression dont la correction a pris plusieurs jours en comptant la reprise de données en prod. Ceci alors que tous les tests unitaires étaient verts, générant par-là une fausse confiance.
Pourquoi c’est bien ?
Le simple fait de tester un vrai scénario métier de bout en bout en partant de l’appel HTTP du client jusqu’au payload JSON de retour en passant par les requêtes en base permet de s’assurer que toute la chaîne fonctionne ensemble. Là où les tests unitaires figent l’implémentation en s’y couplant fortement, nos tests permettent de vérifier un comportement de l’application sans bloquer le refactoring. En couvrant plus de choses (lancement de l’API, injection de dépendances, sérialisation/désérialisation JSON, accès à la base), on a forcément un sentiment de sécurité quand on livre en prod. Je ferai un article plus détaillé très prochainement.
Déploiement continu jusqu’en production
C’est quoi ?
Quand on merge le nouveau code sur la branche principale, il est livré sur tous les environnements y compris la prod. C’est une des conséquences de la confiance que l’on place dans nos tests : on ne craint pas de tout casser puisque nos tests nous disent le contraire. S’il y a un bug, on pourra le corriger simplement, ajouter un test et livrer un correctif rapidement.
Il est cependant possible (et fréquent) que l’on veuille n’activer une fonctionnalité qu’après plusieurs itérations et livraisons. Dans ce cas, on livre la fonctionnalité cachée derrière un feature flag (ou feature toggle). Tout Agicap utilisant ce système, il est bien connu et maîtrisé par les équipes produit. Ainsi, le processus est le suivant :
- Avant de commencer à développer la feature, on se pose la question de savoir si un feature flag sera utile. Si oui, on le crée et on l’active uniquement sur l’environnement de développement.
- Le chemin de code de la feature est caché derrière une instruction du type
if(featureFlagForFeatureX.IsActive()). - Notre PM teste et valide en préproduction, en activant ou désactivant le feature flag à sa guise via une interface dédiée utilisée par toute l’entreprise.
- Lorsqu’il est satisfait du comportement il l’active en production.
- Si tout est OK, on peut maintenant supprimer les
if(), le feature flag et le vieux code inutile, ce qui fait que le nouveau code fait partie intégrante du reste de l’application.
L’inconvénient des feature flags c’est qu’ils demandent un suivi et un ménage rigoureux. Sinon on se retrouve vite avec une liste impressionnante de flags dont on ne sait pas si on veut les garder ou non et, surtout, le code croule sous la complexité introduite pas les if() un peu partout.
Pourquoi c’est bien ?
Pas de barrière entre l’environnement de production et les environnements hors prod. Quand le code est déployé, il l’est partout. De plus, avec les feature flags, la mise à disposition d’une fonctionnalité est entièrement à la main du produit. Pas besoin d’attendre un déploiement de la part des devs, le code est déjà là et prêt à être utilisé. On peut aussi voir si le découpage a été bien fait, si on ne casse vraiment rien avec la fonctionnalité et comparer les 2 comportements. Bref, une flexibilité bienvenue pour tout le monde.
Culture générative
L’ambiance est saine et permet de discuter de la plupart des sujets quotidiennement à coeur ouvert.
C’est quoi ?
Dans l’article d’introduction sur Accelerate, je parlais des différents types de culture identifiés par le modèle de Ron Westrum : pathologique, bureaucratique et générative. Dans ce dernier cas, on est orienté « constructivité » : on va de l’avant, en cas de problème on cherche une solution pérenne et non un coupable, et l’innovation est au coeur des préoccupations.
C’est exactement ce qu’on a dans notre équipe. C’est à la fois très motivant et facilitateur, dans la mesure où on cherche réellement à enlever des obstacles au quotidien plutôt que d’en ajouter. Je n’ai pas rencontré souvent ce type d’organisation donc ça fait vraiment plaisir à vivre.
L’ambiance est saine et permet de discuter de la plupart des sujets quotidiennement à coeur ouvert. On a des espaces dédiés de discussions comme la rétro ou des points en one-to-one, permettant ensuite d’avancer sur les sujets levés.
Pourquoi c’est bien ?
Pas de toxicité, pas (ou peu) de non-dits, on avance. C’est super important car on évite en général d’accumuler les points négatifs en se retenant d’en parler et c’est très sain. Cela permet alors de se focaliser sur le fond du travail en lui-même.
Quelques chiffres
Afin de mesurer nos performances et après discussions avec l’équipe, j’ai mis en place de quoi mesurer les DORA metrics. À savoir :
- Le nombre de bugs détectés chaque semaine et le temps qu’il a fallu pour les corriger ;
- Le nombre de releases (donc jusqu’en production) par semaine ;
- Le nombre de features activées en production par semaine ;
- Le temps entre le moment où une feature arrive dans le board Kanban et le moment où elle est activée en production.
0 bug ???
Parmi les différents chiffres, on peut noter les 0 pour le Change Failure Rate et les Mean Regressions Occurrences. Ce chiffre est trompeur, en fait on a réellement eu 2 bugs sur cette période de 9 mois, d’où la médiane à 0. Chaque bug a pris moins d’une demi-journée avant d’être fixé en production, donc un MTTR de 0 jour.
On peut aussi remarquer le Lead Time for Change à 29, ce qui est beaucoup ! En fait, plusieurs features ont végété plusieurs mois dans la backlog, car jamais priorisées. Elles impactent assez négativement cette métrique ; c’est pourquoi j’ai ajouté la sous-métrique « Time in dev » juste en-dessous pour mettre en évidence le temps réellement passé sur la réalisation technique.
Pour terminer, on peut voir que nous livrions environ 8 fois par semaine en production, soit plus d’une fois par jour en moyenne. Combien d’équipes peuvent dire qu’elles livrent tous les jours en prod en n’ayant que 2 bugs en 9 mois ?
Une stabilité régulière : Accelerate en pratique
Des contraintes exigeantes
C’est là le point crucial des enseignements d’Accelerate : garantir un fonctionnement sans faille aux clients tout en évoluant constamment. Ce qui semble être une gageure dans la plupart des organisations est en fait très réalisable en adoptant quelques pratiques simples.
Attention toutefois car « simple » ne signifie pas forcément facile. Comme dit plus haut, le pair ou le mob programming à temps plein est très énergivore et vient avec tout un lot de contraintes. Il faut savoir découper les tâches, discuter avec les expert·es métier, comprendre ce qui est demandé, accepter de ne pas faire du code parfait pour répondre aux contraintes de delivery, etc… bref, savoir faire partie d’une équipe. Une équipe qui travaille sereinement dans un cadre sain, avec une vélocité et des critères de qualité élevés.
Une équipe, pas un groupe
Je fais ici la distinction entre une véritable équipe et un groupe d’individus. Dans un cas on a une collaboration active entre tous les membres ; dans l’autre chacun·e bosse dans son coin avec un nombre minimal d’interactions avec les autres. Le premier cas est peu confortable et réclame une attention de tous les instants, mais c’est aussi le plus efficace.
Il faut garder à l’esprit que former une équipe est fragile : si des choses importantes sont changées, l’équilibre est mis à mal et on peut vite dérailler. On ajoute une personne ? Il faut l’onboarder, qu’elle s’adapte au mode de fonctionnement et que les autrs s’adaptent aussi. On enlève une personne ? Pareil, l’équipe doit se réadapter. L’organisation interdit telle ou telle pratique (j’ai déjà vu des entreprises où le pair programming n’était pas autorisé) ? Pareil. Il est donc indispensable de savoir s’adapter, faire confiance à la culture générative, discuter ouvertement des problèmes et s’accrocher ensemble. Et ne pas oublier que quelques jours de vacances peuvent faire le plus grand bien !
Il y a certainement d’autres équipes qui fonctionnent ainsi voire mieux, mais force est de constater qu’il s’agit là pour moi d’une expérience professionnelle agréable, probablement une des meilleures. C’est à la fois énergivore et reposant ; énergivore car on n’a souvent pas de temps mort, mais reposant car on n’a pas de stress quand on on livre ou qu’on part en vacances. Tout est serein. On est quasiment sûr de ne pas avoir de bugs et au pire on est capable de les fixer en quelques heures en prod. On s’adapte aux conditions changeantes sur notre périmètre.
Vous êtes intéressé·e par ce type d’organisation d’équipe ? Vous souhaitez le mettre en place chez vous ? Je peux vous y aider ! Contactez-moi via l’un des moyens ci-dessous et je vous répondrai rapidement.
Software developer since 2000, I try to make the right things right. I usually work with .Net (C#) and Azure, mostly because the ecosystem is really friendly and helps me focus on the right things.
I try to avoid unnecessary (a.k.a. accidental) complexity and in general everything that gets in the way of solving the essential complexity induced by the business needs.
This is why I favor a test-first approach to focus on the problem space and ask questions to business experts before even coding the feature.
