Ce que coûte vraiment votre propre outil de suivi du temps

Nous avons été des deux côtés de cette décision. Nous avons construit un outil de suivi du temps et nous l’avons gardé. Nous avons auto-hébergé un serveur de build pendant 7,6 ans et l’avons éteint en 2026. Voici comment savoir auquel des deux vous avez affaire.

Construire son propre outil de suivi du temps avait du sens quand le marché n’avait pas de réponse. Il en a une aujourd’hui, et elle coûte $0 pour un nombre illimité d’utilisateurs : il n’y a donc aucun abonnement que votre développement devrait rentabiliser.

  • L’IA a fait s’effondrer le coût de la version une. La version une n’a jamais été la partie coûteuse.
  • Les estimations publiées situent la maintenance entre 60% et 90% du coût total d’un outil sur toute sa durée de vie.
  • Construire reste le bon choix dans quelques cas précis, listés plus bas.

Gratuit pour un nombre illimité d’utilisateurs. Sans limite de sièges, sans fonctionnalité bloquée derrière un abonnement, et avec une offre dédiée aux associations enregistrées.

Mais l’IA peut construire ça en un week-end

Cette objection est justifiée, et elle l’est un peu plus chaque mois. Les équipes agissent déjà en conséquence : dans l’enquête build-vs-buy 2026 de Retool, menée auprès de 817 personnes qui développent, plus d’un tiers avaient déjà remplacé un outil SaaS par quelque chose qu’elles avaient écrit elles-mêmes.

35%ont déjà remplacé au moins un outil SaaS par un développement maison
78%prévoient de construire davantage d’outils maison en 2026
51%ont construit un logiciel de production que leur équipe utilise aujourd’hui
60%ont construit quelque chose hors du contrôle de la DSI au cours de l’année écoulée

Regardez ensuite comment ces mêmes créateurs travaillent réellement. 72 % utilisent l’IA pour écrire des fragments de code qu’ils intègrent eux-mêmes dans un projet plus vaste, et seuls 31 % obtiennent une application complète par prompts. À peine 8 % livrent du code écrit par l’IA sans modification, et 26 % citent la charge de maintenance comme frein organisationnel.

Le brouillon généré n’est donc pas le livrable. Quelqu’un reste responsable des tests, de la revue de sécurité, des mises à jour de dépendances et de chaque cas limite listé plus bas sur cette page. L’IA a fait s’effondrer le coût de la version une. La version une n’a jamais été la partie coûteuse.

Retool, rapport build-vs-buy, publié en 2026, à partir d’une enquête menée fin 2025 auprès de 817 personnes qui développent. Vérifié en août 2026.

Nous avons mis notre propre build à la retraite après sept ans

7,6ans de CI auto-hébergé

Notre serveur Jenkins a fonctionné du 3 janvier 2019 jusqu’à son arrêt le 10 août 2026. Il était fiable, il était à nous, et le remplacer par un service hébergé était clairement la bonne décision au bout du compte.

2 776jours de service
15 648commits construits
858déploiements en production de Sandtime.io
~2 Minterrogations du dépôt, toutes les deux minutes

L’interrogation s’est exécutée toutes les deux minutes pendant sept ans et demi, le plus souvent pour constater que rien n’avait changé.

Ce qui y a finalement mis fin n’était pas la facture d’hébergement. C’est que la personne qui connaissait le système est partie en congé, et que personne d’autre ne connaissait les accès, les routes réseau, ni où se trouvait quoi que ce soit. C’est le coût que personne n’inscrit dans l’estimation de construction. Tout vit désormais dans le dépôt, où un collègue ou un agent de codage peut simplement le lire.

Et pourtant, l’auto-hébergement était le bon choix en 2019. GitHub Actions n’existait pas. Le CI hébergé en était à ses débuts. La décision était juste au moment où nous l’avons prise et fausse au moment où nous y avons mis fin, car le marché avait comblé le vide entre-temps.

C’est là ce qu’il faut retenir. Une décision de construire n’est pas définitive. Elle a une date de péremption, et presque personne ne programme sa révision. Le marché du suivi du temps s’est comblé il y a plus de dix ans.

Chiffres de notre propre serveur de build, publiés en août 2026. Voir la publication d’origine

Les chiffres racontent la vraie histoire

Les outils internes représentent un engagement plus lourd et plus long que ce que la plupart des équipes chiffrent.

33%
du temps d’ingénierie consacré aux outils internes
45%
dans les entreprises de 5 000 employés ou plus
60-90%
du coût de vie d’un logiciel est de la maintenance, pas la première construction
15,000+
heures d’ingénierie investies dans Sandtime.io jusqu’à présent
Notre propre décompte

La fourchette de maintenance regroupe des estimations de longue date en génie logiciel qui varient fortement selon le type de système : lisez-la comme une fourchette et non comme une prévision pour votre code. Vérifié en août 2026.

Cinq ans de possession, face à $0

Les équipes savent estimer la construction. Les quatre années suivantes, non.

$0$100k$200k$300kAnnée 1Année 2Année 3Année 4Année 5Trois ingénieurs le construisentSandtime.io

Totaux indicatifs sur cinq ans, sur la base de 500 heures d’ingénierie par personne pour la version initiale, d’un taux moyen de $100 de l’heure et d’une maintenance annuelle de 25 % du coût de construction. Ajustez les hypothèses ci-dessous.

Combien cela coûterait-il à votre équipe ?

Ajustez les valeurs pour estimer ce que coûterait réellement la construction, puis le maintien, d’un outil de suivi du temps.

Construction la première année$150 000
Maintenance, 4 années suivantes$150 000
Coût total de possession$300 000
Sandtime.io sur la même période$0
Délai de rentabilité : jamais. L’alternative est déjà gratuite.

Suppose 500 heures d’ingénierie par personne pour une première version, puis une maintenance annuelle chiffrée comme une part de ce coût. Exclut la conception produit, l’AQ, le DevOps, la revue de sécurité et le coût du travail que ces ingénieurs n’ont pas fait à la place.

Ce que vous vous engageriez réellement à construire

Ce n’est pas une liste hypothétique. C’est la liste que nous avons parcourue, et chaque point y figure parce qu’un vrai utilisateur l’a rencontré.

Fuseaux horaires et changement d’heure

Un chronomètre lancé avant un changement d’heure et arrêté après doit tout de même indiquer la bonne durée, dans le fuseau où travaille chaque personne.

Des taux qui évoluent dans le temps

Quand un taux de coût ou de facturation change, les rapports du trimestre précédent doivent continuer d’utiliser le taux alors en vigueur, pas le nouveau.

Détection des chevauchements

Deux saisies couvrant les mêmes minutes gonfleront silencieusement une facture, à moins que quelque chose ne détecte le conflit dès sa création.

Le circuit d’approbation

Soumission, approbation, rejet, rappels, verrouillage des périodes passées, déverrouillages temporaires, et la trace de qui a demandé et résolu chacun d’eux.

Rôles et visibilité

Qui peut voir les heures de qui, quels projets apparaissent à qui, et ce qu’un responsable peut approuver. Chaque réponse est un contrôle de permission quelque part.

Plusieurs devises

Des taux en différentes devises pour différents clients, présentés côte à côte avec les coûts, sans transformer chaque rapport en débat sur les conversions.

Récupérer les données

Des exports Excel et CSV que le service financier acceptera vraiment, dans le format qu’attendent déjà la paie et la facturation.

Partout où les gens saisissent leur temps

Applications de bureau, applications mobiles, extension de navigateur, intégration Slack, API REST et serveur MCP. Chacun a son propre processus de livraison.

Chacun de ces points représente un week-end. Ensemble, ils font 15 000 heures.

Nous le savons car nous l’avons fait aussi

Sandtime.io a commencé comme un outil interne. L’équipe devait suivre le temps par projet et par client, refusait de placer ses collègues sous un logiciel de surveillance, et s’est dit ce que tout le monde se dit : ça ne doit pas être si compliqué.

Assez difficile pour que cela devienne un produit. Des mois de développement, puis les demandes de fonctionnalités, les corrections de bugs, les applications mobiles, les conversions de devises, l’intégration Slack, l’extension de navigateur. Plus de 15 000 heures d’ingénierie plus tard, nous en sommes fiers.

C’est précisément pour cela qu’il est gratuit. Nos deux outils internes ont pris des directions opposées : le suivi du temps est devenu le produit, et le serveur de build est devenu un fardeau. La différence n’a jamais été l’effort. C’était de savoir si quelqu’un d’autre l’avait déjà bien résolu.

Les coûts cachés de la construction en interne

La construction initiale n’est que le début. Voici ce que les équipes ignorent systématiquement.

Développement

Conception, architecture, développement, tests et déploiement. Ce qui commence comme un simple chronomètre devient vite un projet aux cas limites que personne n’avait cadrés.

Maintenance

Corrections de bugs, correctifs de sécurité, mises à jour de dépendances, compatibilité navigateur et versions mobiles. Le travail ne s’arrête jamais une fois la première version livrée.

Coût d’opportunité

Chaque heure d’ingénierie consacrée aux outils internes est une heure non consacrée à votre produit principal. Vos concurrents ne construisent pas leurs propres trackers de temps.

Facteur d’autobus

Former les nouveaux venus, rédiger la documentation et assurer la continuité quand ceux qui l’ont construit s’en vont. Les outils internes deviennent discrètement une dette institutionnelle.

Construire ou acheter, en bref

Le suivi du temps est un problème résolu. Votre temps d’ingénierie vaut plus ailleurs.

Construction en interne

  • Des mois avant qu’il soit vraiment utilisable
  • Des demandes de fonctionnalités constantes de la part de votre propre équipe
  • Les corrections de bugs arrivent en tickets internes urgents
  • Ceux qui l’ont construit partent et emportent le contexte avec eux
  • Pas d’applications mobiles, d’extensions de navigateur ni d’intégrations
  • La revue de sécurité et la protection des données reposent entièrement sur vous

Sandtime.io

  • Commencez à suivre le temps en minutes, pas en mois
  • Les nouvelles fonctionnalités arrivent sans livraison de votre part
  • Les ingénieurs restent sur le travail qui rapporte
  • La documentation et le support humain existent déjà
  • Bureau, mobile, extension de navigateur et Slack inclus
  • La sécurité et la protection des données sont le métier à plein temps de quelqu’un d’autre

Critère par critère

Il existe une troisième option qu’on oublie : achetez l’outil et ne construisez que la couche qui vous appartient vraiment.

Critère de décisionConstruire en interneUtiliser Sandtime.ioL’utiliser et l’étendre
Délai jusqu’à une version utilisableDes moisMinutesQuelques minutes, plus votre propre développement par-dessus
Coût la première annéeSalaires d’ingénieurs$0Uniquement la partie que vous avez choisi de construire
Coût la cinquième annéeSalaires d’ingénieurs, à nouveau$0Uniquement la partie que vous avez choisi de construire
Qui corrige le bug du changement d’heureVotre équipe, au détriment de ce qu’elle fait à la placeNousNous, pour tout ce qui se trouve sous l’API
Qui prend en charge la revue de sécuritéVotre équipeNousPartagée, à la frontière de l’API
Quand la personne qui l’a construit s’en vaL’outil ne devient le travail de personneRien ne changeSeule votre propre couche a besoin d’un responsable
S’adapte à un flux de travail uniqueExactement ce que vous avez spécifiéCe que le produit prend en chargeVotre flux de travail sur nos enregistrements

Quand construire est réellement le bon choix

Parfois, oui. Voici les cas où nous construirions aussi.

Le suivi du temps est ce que vous vendez

Si vous vendez du suivi du temps, ce n’est pas un outil interne. C’est votre produit, et tout ce qui figure sur cette page est votre feuille de route plutôt que vos frais généraux.

Le flux de travail est votre véritable avantage

Si votre façon d’enregistrer le travail est vraiment ce pour quoi vos clients vous paient, un outil générique rabotera votre avantage.

Une exigence stricte de résidence des données

Les réseaux isolés et les règles strictes de résidence des données sont de vraies contraintes. Si aucun fournisseur ne peut satisfaire les vôtres, la décision est déjà prise.

Cela est livré dans votre produit

Si le suivi du temps doit vivre à l’intérieur d’un logiciel que vous livrez à vos propres clients, vous construisez une fonctionnalité, vous n’adoptez pas un outil.

Le marché n’a pas encore de réponse

Auto-héberger notre CI en 2019 était juste, car GitHub Actions n’existait pas. Quand le marché n’a pas de réponse, construire est la seule réponse.

Si l’un de ces cas s’applique, construisez. Puis notez dans l’agenda une date pour vérifier s’il s’applique toujours, car c’est cette révision que presque tout le monde saute.

Questions sur construire ou acheter

Est-il moins cher de construire ou d’acheter un outil de suivi du temps ?

Acheter revient moins cher ici pour une raison inhabituelle : Sandtime.io est gratuit pour un nombre illimité d’utilisateurs, il n’y a donc aucun abonnement que le développement devrait rentabiliser. Dans une comparaison classique, on met en balance un développement ponctuel et une licence récurrente. Face à $0, le développement n’est jamais rentabilisé.

L’IA peut-elle simplement nous construire un outil de suivi du temps aujourd’hui ?

Elle écrit vite un minuteur qui fonctionne, et c’est réellement nouveau. Cela ne change pas qui prend en charge les tests, la revue de sécurité, les mises à jour de dépendances et les cas limites qui arrivent ensuite. Dans l’enquête 2026 de Retool, seuls 8% des équipes ont livré du code écrit par l’IA sans le modifier, et 72% s’en sont servies pour des fragments qu’elles intégraient elles-mêmes.

Combien de temps faut-il pour construire un outil de suivi du temps ?

Un simple chronomètre se code en quelques jours. Un outil sur lequel votre service financier facturera prend bien plus longtemps, car le difficile n’est pas le chronomètre mais le changement d’heure, les taux historiques, les saisies qui se chevauchent, les approbations et les exports. Sandtime.io a demandé plus de 15 000 heures d’ingénierie à ce jour.

Quelle est la partie la plus difficile de la construction d’un suivi du temps ?

L’exactitude dans la durée. Un chronomètre qui traverse un changement d’heure, un taux modifié en mars qui ne doit pas réécrire les rapports de février, et deux saisies couvrant les mêmes minutes : chacun est facile à rater et coûteux à découvrir sur une facture.

Quand construire le vôtre a-t-il vraiment du sens ?

Quand le suivi du temps est le produit que vous vendez, quand le flux de travail lui-même est votre avantage concurrentiel, quand les règles de résidence des données ne laissent aucune option fournisseur, quand cela doit être livré dans votre propre produit, ou quand le marché n’a vraiment pas encore de réponse. En dehors de ces cas, le marché s’est comblé depuis longtemps.

Sandtime.io est-il vraiment gratuit pour un nombre illimité d’utilisateurs ?

Oui. Le produit en service est gratuit pour un nombre illimité d’utilisateurs et de projets, sans facturation par siège, sans carte bancaire et sans fonctionnalité bloquée derrière un abonnement. Les associations enregistrées peuvent bénéficier d’une offre dédiée.

Pouvons-nous utiliser Sandtime.io et construire malgré tout notre propre couche par-dessus ?

Oui, et c’est souvent la bonne réponse. Suivez le temps dans Sandtime.io, lisez les enregistrements via API REST ou serveur MCP, et ne développez que la couche qui vous est propre. Aucune de ces deux interfaces n’a encore de politique de versionnage publiée : prévoyez des évolutions et gardez les exports à disposition.