Une entreprise paye en 2026, pour son outil de suivi du temps, 6 500 € par an : 50 utilisateurs, au tarif par personne. Soit 32 500 € sur cinq ans, sans compter les hausses de tarif.
Et son équipe s'en plaint. L'outil est lent, l'interface compliquée, et des fonctions essentielles restent bloquées, réservées aux forfaits supérieurs alors que la facture augmente déjà. Nous proposons d'en construire un.
Un abonnement facturé par utilisateur grandit avec votre équipe et les fonctionnalités que vous débloquez
La facture a deux moteurs. Le premier est mécanique : chaque nouvel arrivant ajoute une licence. Le second est plus discret : les fonctions sont réparties entre des forfaits successifs, et celles dont une équipe a vraiment besoin, comme connecter ses données à un autre outil ou limiter ce que chacun voit dans les rapports, sont rarement dans le forfait de base. Pour les obtenir, il faut monter d'un cran, souvent pour tous les utilisateurs à la fois.
Chaque besoin nouveau se paie donc deux fois : par le nombre de licences et par le niveau de forfait. La facture suit vos effectifs et la grille de l'éditeur, rarement le service que l'outil vous rend.
Dans beaucoup d'entreprises, comme chez nous, cette ligne de dépense augmente nettement depuis deux ou trois ans. Le modèle a pourtant de vraies qualités : rien à installer, rien à maintenir, un outil prêt le jour même. Mais quand vos équipes l'utilisent tous les jours sans l'aimer, et que la fonction qui leur manque se trouve toujours au forfait du dessus, la question finit par se poser.
Pendant longtemps, la réponse était vite trouvée. Un outil sur mesure coûtait trop cher pour un besoin aussi courant que la saisie des temps. Ce calcul change, pas pour tous les outils, mais pour une partie d'entre eux. Et pas grâce à l'IA seule : ce qui rend l'opération sûre, c'est une chaîne de développement maîtrisée de bout en bout, qui conçoit, contrôle, recette, déploie et documente chaque évolution.
Partir des usages : saisir vite, facturer juste
Avant d'écrire du code, nous regardons comment l'équipe travaille. Chacun doit saisir ses temps en quelques secondes, sur mobile comme sur ordinateur. Ces temps alimentent ensuite la facturation, l'intranet et les tableaux de bord de l'entreprise.
Un outil simple à utiliser, donc, mais avec de vraies responsabilités derrière. Une erreur de saisie ou de calcul finit sur une facture, ou fausse le pilotage d'un projet. Le premier périmètre doit être utile dès le premier jour, et surtout fiable. Il doit aussi pouvoir évoluer ensuite sans jamais remettre cette fiabilité en jeu.
Quatre jours pour une première version et ses moyens d'essai
Nous ne partons pas de zéro. Nous disposons de bases de code éprouvées, de composants d'interface réutilisables, de notre framework d'agents IA et d'une chaîne de développement déjà en place. Chaque projet profite de ce que les précédents ont permis de construire.
Deux personnes de GDN mènent le projet. Plusieurs agents IA travaillent en parallèle, sous le pilotage de nos ingénieurs. L'architecture, les intégrations, les choix techniques et la validation restent de leur responsabilité. L'IA accélère, l'ingénierie sécurise.
Au bout de quatre jours, l'entreprise dispose d'une première version opérationnelle, centrée sur les fonctions essentielles. De quoi vérifier sur le terrain que l'outil répond au besoin, avant d'aller plus loin.
Le plus important est ailleurs. Dans ces quatre jours, nous installons aussi la chaîne qui permet de faire évoluer l'outil sans le casser :
- une intégration continue, qui vérifie automatiquement chaque modification avant de l'accepter ;
- des tests automatisés, unitaires, d'interface et de sécurité, complétés par une revue de code, qui signalent toute régression ;
- des environnements de test créés à la demande, pour recetter chaque évolution à part, sans toucher à l'outil en service ;
- un déploiement scripté, identique d'une mise en production à l'autre ;
- un code versionné, dont chaque changement est rattaché à la demande qui l'a motivé.
Ce travail ne se voit pas dans une démonstration. C'est pourtant lui qui fait la différence entre un outil livré vite et un outil qui reste maîtrisé dans la durée.
Un jour pour la mise en production, cinq jours pour dépasser l'ancien outil
La mise en production prend une journée. Dernières vérifications dans l'environnement cible, contrôle des connexions à la facturation, à l'intranet et aux tableaux de bord. Puis les sauvegardes, et la mise en service.
Viennent ensuite cinq jours pour aller au-delà du simple remplacement. Les fonctions que l'ancien abonnement réservait à un forfait supérieur sont disponibles dès le lancement, sans supplément. S'y ajoutent de nombreuses fonctions que l'équipe n'a jamais eues, à commencer par celles qui changent son quotidien :
- chacun choisit son fuseau horaire ; ses horaires, ses totaux et ses exports suivent ce choix, sans qu'aucun temps enregistré ne soit réécrit ;
- le rapport de l'entreprise compte tout le monde dans un fuseau unique : deux lecteurs situés dans deux fuseaux différents y trouvent le même total du mois ;
- les filtres du rapport s'appliquent d'un clic, pilotent toute la page, et l'export reprend exactement ce qui est affiché ;
- un chef de projet ne voit dans les rapports que les personnes et les projets dont il a la charge, et l'outil refuse toute demande qui sort de ce périmètre ;
- les durées portent leur unité, pour ne plus confondre un total d'heures avec le compteur du chronomètre ;
- une confirmation est demandée avant toute action destructrice, comme supprimer un client ou désactiver un compte, et un formulaire modifié ne se ferme pas sans prévenir ;
- les formulaires se valident et se ferment au clavier, et un lien d'accès direct au contenu facilite la navigation au clavier ou avec un lecteur d'écran ;
- les descriptions des saisies peuvent atteindre 16 000 caractères, contre 255 dans la première version ;
- seul un administrateur crée les comptes : l'inscription libre disparaît.
Et ce qui ne se voit pas à l'écran, mais compte autant :
- une interface d'intégration en lecture seule pour l'intranet et les tableaux de bord : des jetons d'accès aux droits précis, qui expirent au bout d'un an, et chaque appel journalisé ;
- des comptes techniques réservés à ces intégrations, sans aucun accès à l'application ;
- une limitation du nombre de requêtes sur les accès sensibles : connexion, exports, synchronisation ;
- des en-têtes de sécurité, qui empêchent par exemple d'afficher l'outil à l'intérieur d'une autre page ;
- une documentation complète de l'interface de programmation, et un test qui vérifie qu'aucune route n'y échappe.
C'est là que la chaîne de développement prend tout son sens. Chaque évolution est testée automatiquement, recettée sur un environnement dédié, puis déployée et documentée. Cinq jours d'évolutions rapides, sans fragiliser ce qui fonctionne déjà. Sans cette chaîne, la même vitesse serait une prise de risque.
Trois ans d'historique repris, une bascule du jour au lendemain
Construire l'outil n'est souvent pas ce qui inquiète le plus. C'est de quitter l'ancien. Que deviennent trois ans de temps saisis ? Et l'intranet, et les tableaux de bord, qui lisent leurs données dans l'ancien outil ?
L'historique complet est repris à partir des exports de l'ancien outil. Chaque import passe d'abord par une simulation, qui liste les créations, les anomalies et les totaux sans rien écrire. L'import peut être rejoué autant que nécessaire, sans jamais toucher aux saisies faites dans le nouvel outil.
Les anciens membres de l'équipe sont conservés avec des comptes désactivés, pour que leurs temps restent rattachés aux bons projets. Les fichiers d'export contiennent des données personnelles : ils sont supprimés après l'import, et chaque import est tracé.
L'intranet et les tableaux de bord lisent désormais le nouvel outil par l'interface d'intégration, en lecture seule. Pour eux, le changement passe inaperçu.
La bascule se fait en une fois, l'ancien outil gelé. Le nouveau devient la seule source de vérité, passé compris, et l'équipe abandonne l'ancien du jour au lendemain. Ses retours tiennent en peu de mots : beaucoup plus rapide, beaucoup plus simple.
Comparer cinq ans d'abonnement à cinq ans de vie du logiciel
Faisons le compte. Le développement complet, de la première version aux améliorations, coûte 5 000 € HT pour moins de deux semaines de travail. L'abonnement remplacé représente 6 500 € par an, soit 32 500 € sur cinq ans.
Arrêtée là, la comparaison serait trop flatteuse. Un logiciel continue à vivre après sa livraison : il faut l'héberger, surveiller son serveur, appliquer les mises à jour de sécurité. Ici, l'outil est hébergé sur AWS Lightsail pour 76 € par mois, et la maintenance proactive du serveur représente environ 100 € par mois. Soit 10 560 € sur cinq ans.
Développement et exploitation compris, l'outil revient à environ 15 560 € sur cinq ans, contre 32 500 € pour l'abonnement. L'écart, près de 17 000 €, finance les évolutions à venir. C'est là que se joue la vraie comparaison : un abonnement vous apporte les évolutions que l'éditeur décide, votre outil reçoit celles que vos équipes demandent, au rythme que vous choisissez.
Une partie de la différence ne se chiffre pas directement. L'infrastructure est entièrement décrite en code : elle peut être recréée à l'identique, agrandie si l'usage augmente, ou déplacée chez un autre hébergeur si l'entreprise le décide un jour. L'entreprise garde la main sur son code, ses données et la chaîne qui les fait évoluer. Les fonctions dont son équipe a besoin ne dépendent plus de la grille tarifaire d'un éditeur.
Un SaaS du marché ou votre SaaS, le choix dépend de ses fonctionnalités, de ce qu'il apporte vraiment à vos équipes et de ce qu'il vous coûtera sur la durée. Quand un besoin standard est bien couvert, qu'il évolue peu et que l'outil plaît, le reconstruire a peu d'intérêt : l'éditeur finance pour vous des fonctions que vous n'auriez aucune raison de développer seul. Votre propre outil devient intéressant quand plusieurs signaux se cumulent : une facture qui monte avec les effectifs et les forfaits, un outil que les équipes subissent, des besoins propres à votre façon de travailler, des données qui doivent circuler vers vos autres outils.
Une condition, enfin, ne se négocie pas. Posséder son logiciel, c'est en assumer les évolutions permanentes, la montée en charge et la sécurité. Sans une chaîne de développement maîtrisée, qui teste, recette, déploie et documente chaque changement, le sur mesure devient vite un nouveau point de fragilité. Avec elle, il reste sous contrôle en toutes circonstances. Cette exigence a un coût, mais le calcul reste souvent avantageux, et il l'est d'autant plus que vos utilisateurs sont nombreux : l'abonnement grandit avec chaque licence, le coût de votre outil beaucoup moins. La première version peut aussi être transmise à vos équipes internes, avec la chaîne qui l'accompagne ; nous les accompagnons ensuite pour qu'elles prennent en main les nouveaux développements proprement.
Une réserve sur les délais. Dix jours, c'est le résultat d'un périmètre précis et d'une chaîne préparée de longue date. Chaque projet a ses contraintes et son calendrier : ce chiffre est un repère, pas une promesse.
La vitesse se prépare à l'atelier
On pourrait résumer ce projet d'une formule : le SaaS est mort, vive votre SaaS. La formule est provocatrice. La possibilité, elle, est concrète.
Ce qui rend ces dix jours possibles n'est pas l'IA seule. C'est tout ce qui existe avant le premier jour : le code éprouvé, la chaîne qui contrôle, recette, déploie et documente chaque évolution, et deux ingénieurs qui savent quoi vérifier. C'est aussi cette chaîne qui garantit la suite : l'outil pourra continuer d'évoluer, absorber plus d'utilisateurs et rester sûr, sans que personne ne perde la maîtrise de ce qui part en production.
Reprenez vos abonnements de l'année. Lequel payez-vous pour un outil que vos équipes subissent, alors qu'elles sauraient très bien décrire celui dont elles ont besoin ? C'est par celui-là que la question mérite d'être posée.
Auteur · M.Baudoux - Développement logiciel & accompagnement IA