Construire ou acheter un suivi du temps : ce que nous a appris le retrait de notre propre build

Le 10 août 2026, nous avons éteint un serveur de build qui tournait depuis janvier 2019. Il était fiable. Il était à nous. Le retirer était manifestement le bon choix à la fin, et l’auto-héberger était tout aussi manifestement le bon choix au début. Ces deux affirmations sont vraies, et l’écart entre elles constitue toute la question du construire ou acheter.

Nous venons de retirer l’un de nos propres outils internes

La plupart des articles sur le construire ou acheter sont écrits par des gens qui vendent le camp de l’achat et n’ont jamais porté celui de la construction. Nous avons porté les deux, dans des directions opposées, et ce contraste est ce que nous pouvons offrir de plus utile.

Ce dernier chiffre mérite qu’on s’y arrête. Environ deux millions de fois, toutes les deux minutes pendant sept ans et demi, le serveur a demandé au dépôt si quelque chose avait changé. Presque toujours, rien n’avait changé.

La facture n’a jamais été le problème

L’auto-hébergement se discute d’ordinaire sur le terrain du coût d’infrastructure. Ce n’est pas ce qui a mis fin à celui-ci.

Ce qui y a mis fin, 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. Les builds continuaient de tourner, mais personne ne pouvait y changer quoi que ce soit avec assurance. C’est la ligne absente de toutes les estimations de construction jamais rédigées : non pas ce que coûte l’exploitation, mais ce que coûte le moment où la seule personne détenant le contexte est indisponible.

Tout vit désormais dans le dépôt. Un collègue peut le lire. Un agent de codage aussi, ce qui compte davantage que nous ne l’avions prévu.

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

C’est la première objection que soulève toute équipe d’ingénierie en 2026, et elle est légitime. Elle est aussi un peu plus vraie chaque mois, et les équipes passent à l’acte plutôt que d’en parler.

Retool, rapport construire ou acheter publié en 2026, basé sur une enquête auprès de 817 créateurs menée fin 2025. Un peu plus d’un tiers des répondants se déclaraient ingénieurs logiciels. Lire le rapport. Vérifié en août 2026.

La tendance est donc réelle. Mais regardez comment ces mêmes créateurs décrivent leur propre travail, car le détail contredit le titre :

• 72 % utilisent l’IA pour écrire des fragments de code qu’ils intègrent eux-mêmes dans un projet plus vaste.
• 31 % obtiennent une application complète par prompts.
• 8 % livrent du code écrit par l’IA sans modification.
• 44 % testent rigoureusement avant tout déploiement.
• 26 % citent la charge de maintenance comme frein organisationnel.

Le brouillon généré n’est pas le livrable. Quelqu’un l’intègre, le teste, en fait la revue de sécurité et en assume la responsabilité quand une dépendance casse dix-huit mois plus tard. L’IA a fait s’effondrer le coût de la version une, et la version une n’a jamais été la partie coûteuse. Notre serveur de build n’a pas coûté 7,6 ans d’attention parce qu’écrire le premier Jenkinsfile était difficile.

Ce que coûtent vraiment cinq ans de possession

C’est là que les équipes se trompent. La construction est estimée. Les quatre années qui suivent ne le sont pas.

Les estimations couramment citées en génie logiciel situent la maintenance entre 60 % et 80 % du coût de vie total d’un système, et retiennent que, sur toute la durée d’exploitation, la maintenance représente deux à quatre fois l’investissement de développement initial. Les chiffres varient fortement selon le type de système : traitez-les comme une fourchette et non comme une prévision, mais la direction ne fait pas débat.

La taille de l’équipe fixe la pente. Le temps fixe le total, et c’est cette forme que les équipes n’imaginent pas au moment de valider la première version :

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 chaque hypothèse dans le calculateur construire ou acheter.

Pourquoi le délai de rentabilité n’existe pas

Une comparaison classique met en balance un développement unique et une licence récurrente. Vous divisez, vous obtenez un point d’équilibre en mois, et vous débattez du taux d’actualisation.

Ce calcul exige un abonnement en face. Sandtime.io est gratuit pour un nombre illimité d’utilisateurs et de projets, sans frais par siège et sans blocage incitant à monter en gamme. Divisez n’importe quel coût de construction par $0 de licences évitées et il n’y a aucun point d’équilibre à trouver. Le développement n’est pas lent à s’amortir. Il ne s’amortit pas.

C’est inhabituel, et c’est l’argument le plus fort de cette page. C’est aussi celui qui s’évaporerait si notre tarification changeait, ce qu’il vaut mieux dire ouvertement que dissimuler.

Ce que vous vous engageriez réellement à construire

Ce n’est pas une liste hypothétique. C’est celle que nous avons parcourue en plus de 15 000 heures d’ingénierie, et chaque point y figure parce qu’un vrai utilisateur l’a rencontré.

Chaque ligne prise isolément représente un week-end. La colonne de gauche est ce qui est cadré. Celle de droite est ce qui finit par être livré, après le troisième litige de facturation.

Quand construire est réellement le bon choix

Parfois, oui, et un article qui prétendrait le contraire ne mériterait pas d’être lu. Voici les cas où nous construirions aussi.

Si l’un de ces cas s’applique, construisez. Puis notez dans l’agenda une date pour vérifier s’il s’applique toujours. Les marchés se comblent. Le nôtre l’a fait en sept ans, pendant que personne ne regardait. Cette révision est l’étape que presque tout le monde saute, et c’est précisément ce qui transforme une bonne décision en fardeau.

L’option qu’on oublie : achetez-le et construisez la partie fine

La plupart des équipes qui veulent construire ne veulent pas vraiment un chronomètre. Elles veulent un rapport précis, leur propre logique de facturation, ou un tableau de bord à la forme de leur activité. Vous pouvez avoir tout cela sans hériter des bugs liés au changement d’heure.

L’API REST et le serveur MCP portent tous deux actuellement la mention aperçu pour développeurs. Aucune limite de débit, politique de versionnage ou garantie de niveau de service n’est encore publiée : prévoyez donc des évolutions et gardez les exports dans la boucle. C’est une limitation réelle, à peser avant de confier un processus critique à l’une ou l’autre de ces interfaces.

Encore un point, si vous opérez dans l’Union européenne

Les relevés du temps de travail n’y sont pas seulement une commodité interne. Dans l’affaire CCOO contre Deutsche Bank (C-55/18, 14 mai 2019), la Cour de justice de l’Union européenne a jugé que les États membres doivent imposer aux employeurs de mettre en place un système objectif, fiable et accessible permettant de mesurer la durée du temps de travail journalier de chaque travailleur.

Construisez le vôtre et cette obligation, ainsi que chacune de ses évolutions futures, devient quelque chose que votre équipe maintient et revérifie. Ceci est un élément de contexte et non un conseil juridique, et Sandtime.io ne revendique aucune conformité certifiée dans quelque juridiction que ce soit. Vous pouvez lire l’arrêt directement.

Comment décider en un après-midi

Posez trois questions, dans cet ordre.

1. Le suivi du temps est-il quelque chose que nous vendons, ou que nous utilisons ? Si vous le vendez, arrêtez de lire. Si vous l’utilisez, continuez.
2. Quelque chose sur le marché résout-il ce problème ? Pour le suivi du temps, la réponse honnête est oui, et ce depuis plus de dix ans. Pour votre problème véritablement inhabituel, peut-être pas, et c’est un vrai motif de construire.
3. Si nous le construisons, qui en sera responsable la troisième année ? Nommez la personne. Si vous ne le pouvez pas, vous venez de trouver le mode de défaillance qui a mis notre serveur de build à la retraite.

Ce qu’il faut retenir

Nous n’allons pas vous dire que construire du logiciel est une erreur. Nous avons construit un outil de suivi du temps et il est devenu notre produit. Nous avons construit une chaîne de CI et elle est devenue un fardeau. L’effort était comparable. La différence tenait à ce que quelqu’un d’autre avait, ou non, déjà bien résolu le problème.

Pour le suivi du temps, quelqu’un l’a fait. Cela coûte $0 pour un nombre illimité d’utilisateurs, et vous pouvez commencer à l’utiliser dès aujourd’hui au lieu de programmer la réunion de lancement.