Tiime — Livrer des modules comptables prêts pour la production

Contexte

Tiime est un éditeur SaaS luxembourgeois qui outille les cabinets d’expertise comptable avec une plateforme intégrée : gestion de clients, automatisations comptables, communication cabinet/client. Une équipe produit pluridisciplinaire, une architecture microservices déjà en place, et une particularité rare : les Product Owners étaient eux-mêmes experts-comptables, pas des chefs de produit généralistes.

J’y suis intervenu deux ans comme Senior IT Consultant, via Alvernia. Pas comme architecte, pas comme tech lead — comme développeur senior de confiance, responsable de bout en bout sur les périmètres qui m’étaient confiés.

Problématique

Les modules comptables ne sont pas des features comme les autres. Un plan d’amortissement mal calculé, c’est une erreur qui finit dans un bilan officiel. Une écriture automatisée qui oublie une règle de TVA, c’est un contrôle fiscal qui va mal se passer. La tolérance à l’erreur est structurellement plus basse que dans la plupart des produits SaaS.

À cela s’ajoutait la dynamique particulière de la relation avec les PO : quand un expert-comptable te décrit un besoin, il te le décrit avec la précision du métier, pas avec la précision d’un cahier des charges logiciel. À toi de traduire cette précision métier en design technique qui tient.

Approche

Ma valeur sur cette mission ne venait pas d’une intervention structurante sur l’architecture — elle existait déjà et fonctionnait bien. Elle venait de la fiabilité de livraison sur des périmètres sensibles. Pour ça, trois principes que j’appliquais systématiquement :

Comprendre le métier avant d’écrire une ligne de code. Les PO comptables savaient ce qu’il fallait faire, pas toujours ce que ça allait coûter côté technique. Passer du temps à discuter chaque règle métier en détail évitait ensuite de développer une fonctionnalité qui semble correcte mais qui rate un cas limite dont on aurait pu parler dix minutes en amont.

Penser en lifecycle, pas en ticket. Un module comptable n’est pas livré quand il passe la revue de code. Il est livré quand il tourne en production, que les clients l’utilisent, que les bugs remontés ont été corrigés, et qu’on sait comment le faire évoluer sans tout casser. Je prenais en charge mes périmètres sur toute cette durée, pas juste sur la phase de dev initial.

Écrire pour le développeur suivant. Dans une équipe produit qui tourne, le code que tu livres sera maintenu par quelqu’un d’autre dans six mois. Tests bien écrits, code qui raconte ce qu’il fait sans avoir besoin d’un commentaire, architecture qui rend les changements futurs simples plutôt que spectaculaires. Ça prend plus de temps à la livraison. Ça en fait gagner énormément sur la durée.

Réalisation

Le périmètre que je mets en avant ici est l’automatisation des plans d’amortissement. C’est un sujet où les règles comptables sont précises, où les cas limites sont nombreux (amortissements dégressifs, linéaires, immobilisations incorporelles, ajustements fiscaux), et où l’automatisation bien faite fait gagner un temps considérable aux cabinets.

Le travail a consisté à concevoir, développer et mettre en production un module qui prenait en charge la génération automatique des plans d’amortissement selon les règles comptables applicables, avec les garde-fous nécessaires : validation des paramètres d’entrée, gestion explicite des cas particuliers, traçabilité des calculs pour que les comptables puissent expliquer à leurs clients ce que le système a fait et pourquoi.

Au-delà de ce module, j’ai contribué sur d’autres chantiers de modules métier (vérification de cohérence, communication cabinet/client), toujours avec la même posture : responsable du périmètre, interlocuteur direct des PO, livraison bout en bout.

Résultat

Les automatisations livrées tournent en production et font partie du quotidien des cabinets clients de Tiime. L’impact n’est pas mesurable en un chiffre flashy — il se mesure en heures gagnées chaque mois par des experts-comptables qui peuvent se concentrer sur le conseil à leurs clients plutôt que sur des calculs répétitifs.

Ce qui a marqué cette mission pour moi, c’est la confiance qui m’était accordée sur mes périmètres. Pas de chef qui valide chaque commit, pas de micro-management. Un cadre clair, des attentes claires, et la liberté de livrer proprement.

Ce que j’en retiens

Deux choses.

Quand le PO est un expert métier, le développeur doit monter d’un cran. Dans une équipe produit classique, le PO joue souvent le rôle de tampon entre le métier brut et le développeur. Chez Tiime, ce tampon n’existait pas — et ça forçait à un niveau d’écoute et de questionnement plus fin. C’est un mode de travail que j’ai trouvé particulièrement efficace, et qui m’a marqué depuis.

Être responsable d’un périmètre, ce n’est pas juste le livrer. C’est porter ce qui tourne en production. Beaucoup de développeurs considèrent leur travail fini à la merge de la pull request. La vraie valeur ajoutée commence après : quand le code tourne pour de vrai, quand les utilisateurs remontent des cas que personne n’avait imaginés, quand il faut faire évoluer ce qu’on a écrit il y a six mois. C’est là qu’on voit la différence entre un développeur qui livre et un développeur qui s’engage.