Deux ans sur un logiciel, quatre jours sur un autre : pourquoi on construit nos propres produits

Peich Technologies vend des sites web et des opérations web sur abonnement. C'est le métier. En parallèle, on construit et on exploite trois logiciels qui n'ont rien à voir avec ça : ForgeMRP, un système de planification de production pour les ateliers d'usinage, Caribooks, un connecteur entre QuickBooks et un assistant IA, et Type Parts, un générateur de pièces CAO paramétriques.

La question revient assez souvent pour mériter une réponse écrite : pourquoi une agence qui facture des sites web passe-t-elle son temps sur des produits que personne ne lui a demandés ?

La réponse courte est qu'une agence, structurellement, arrête d'apprendre à la facture. Et qu'un produit qu'on exploite soi-même est le seul mécanisme qu'on ait trouvé pour continuer.

La réponse courte, pour les pressés

Une agence de développement web est jugée le jour de la livraison. C'est à ce moment qu'elle est payée, et c'est donc ce moment qu'elle optimise. Si l'architecture retenue était mauvaise, c'est le client qui le découvre au huitième mois, pas elle. Construire et exploiter ses propres logiciels ferme cette boucle : on paie l'hébergement, on répond aux courriels de support, on regarde une inscription mourir à l'étape du consentement OAuth. Chez Peich Technologies, trois produits jouent ce rôle. ForgeMRP, un logiciel de planification de production, tourne depuis deux ans et enseigne ce qu'un système devient quand de vraies données s'y accumulent. Caribooks et Type Parts ont été construits en quelques jours, comme des tests. L'écart entre ces deux calendriers n'est pas une question de talent. C'est la compétence qu'un client achète réellement : reconnaître à l'avance dans laquelle des deux catégories tombe son projet.

Une agence arrête d'apprendre à la facture

Regardez les incitatifs sans indulgence. Une agence est évaluée sur ce qui est visible le jour de la mise en ligne : le design, la démo, la passation. C'est là qu'elle est payée et c'est là que le jugement se fige. Rien, dans cette structure, ne la pousse à se soucier du huitième mois.

Le client, lui, s'en soucie. Mais il n'a aucun moyen de relier ce qu'il vit au choix qui l'a causé. Son formulaire tombe en panne, son site ralentit, une mise à jour casse une page. Il constate le symptôme sans jamais voir la décision d'architecture prise dix-huit mois plus tôt par quelqu'un qui n'est plus là. C'est comme ça qu'un site livré dans les règles finit par pourrir tranquillement.

Une agence peut tourner des années sans jamais recevoir ce retour. Elle produit, elle livre, elle encaisse, et elle recommence avec les mêmes réflexes. Personne n'est négligent là-dedans. La boucle de rétroaction n'existe simplement pas.

Un produit qu'on exploite soi-même la reconstitue de force. On paie la facture d'hébergement de Caribooks tous les mois. On répond au courriel qui demande pourquoi la connexion QuickBooks a expiré. Chaque irritant de ce genre est une décision prise un après-midi, à laquelle on est maintenant attaché.

Ce que deux ans sur le même logiciel apprennent

ForgeMRP est le cas long. Le projet a deux ans et il en est déjà à son deuxième dépôt : le premier a été abandonné après une grosse migration, et celui qui l'a remplacé porte 4 200 changements depuis l'été 2025. C'est un logiciel de planification de production : soumissions, jobs, bons de travail, achats, sous-traitance. Un domaine dense, des utilisateurs avec des données réelles. On a pu repartir d'un dépôt neuf ; on n'a jamais pu repartir de données neuves.

Deux choses trouvées dans ce système en avril 2026 valent mieux qu'un discours.

Le modèle dans le code s'éloigne du modèle dans les données. Le type `WorkOrderStatus`, écrit à la main, déclarait neuf statuts possibles pour un bon de travail. L'énumération correspondante dans la base de données en comptait cinq. En allant compter les lignes en production, on a trouvé exactement ces cinq-là, et zéro ligne portant l'un des six autres. Des composants d'interface géraient donc, depuis des mois, des états qui n'avaient jamais existé ailleurs que dans la tête de quelqu'un. La décision a été de rétrécir le code jusqu'à la base plutôt que l'inverse, et de laisser le compilateur trouver le reste.

Un système vivant accumule des choses que personne n'utilise. Un audit du schéma a sorti huit objets sans aucune référence dans le code : des vues remplacées avant même l'arrivée du multi-locataire, une colonne contenant seize lignes de données pour laquelle aucun écran ne permettait de saisir quoi que ce soit. On ne trouve pas ça en lisant le code. Il faut croiser ce qui est référencé avec ce qui contient réellement des données.

Il y a une troisième leçon, moins spectaculaire et plus utile. Le dépôt contient un glossaire qui fixe le vocabulaire du domaine, avec pour chaque terme une liste de mots à ne pas employer. Un Job n'est pas un Work Order, une Operation n'est pas un Process. Ça peut passer pour de la coquetterie. Après deux ans, c'est de l'infrastructure : quand les mots se confondent, le schéma se confond, et les écrans avec.

Aucune de ces trois leçons n'arrive dans un projet livré puis remis. Elles demandent qu'on reste attaché au système pendant que de vraies données s'y accumulent.

Ce que quelques jours apprennent

Caribooks et Type Parts sont l'autre extrême. Caribooks est passé de l'idée à un produit en ligne qui facture, à caribooks.com, en une seule journée de travail. Type Parts a été construit en quatre jours, du 3 au 6 septembre 2026.

La leçon n'est pas celle qu'on attend. Nous avions estimé la mauvaise chose.

Quand on a monté Caribooks, le travail de conception et de développement n'a pas été ce qui a déterminé la date de mise en ligne. Ce qui l'a déterminée, c'est la suite d'étapes qui exigent qu'un humain ou un tiers agisse : un écran de consentement OAuth à faire approuver, une propagation DNS, un réglage de compte de paiement, un formulaire à remplir chez un fournisseur. Chacune est courte. Mises bout à bout et dépendantes les unes des autres, elles sont le calendrier.

Depuis, quand un client demande combien de temps ça prendra, on ne compte plus les fonctionnalités. On compte les portes : qui doit cliquer sur quoi, quelle approbation externe est nécessaire, combien de fois il faudra attendre une réponse qui ne dépend pas de nous. La réponse est souvent plus honnête, et parfois moins agréable à entendre.

Savoir lequel des deux vous avez devant vous

Un projet à quatre jours et un projet à deux ans ne se distinguent pas par leur cahier des charges. Ils se distinguent par ce qui arrive quand on se trompe. Type Parts se trompe et on le refait : il n'a pas d'utilisateurs avec des données à préserver, pas d'historique, rien qui casse en aval. ForgeMRP se trompe et un atelier planifie sa production sur une information fausse.

Ce qui est coûteux dans un logiciel, ce n'est pas de l'écrire. C'est d'avoir tort en production, avec de vraies données et de vrais utilisateurs par-dessus. Ce coût-là ne baisse pas, et c'est lui qui sépare les deux calendriers.

La conséquence pratique est simple à énoncer. Devant un projet de la première catégorie, la bonne réponse est de le construire pour de vrai et de le mettre devant quelqu'un, au lieu d'organiser trois mois d'entretiens de validation. Devant un projet de la seconde, la prudence redevient entièrement justifiée : on migre par étapes, on garde une porte de sortie, on ne remplace pas un système en service pendant une nuit.

Se tromper de catégorie coûte cher dans les deux sens. Traiter un test comme un système critique fait perdre des mois. Traiter un système critique comme un test fait perdre des données.

Ce que ça change pour votre projet

Trois choses qu'on fait différemment à cause de ces produits.

On estime en portes, pas en fonctionnalités. Les délais qu'on annonce comptent les approbations, les accès et les tiers dont on dépend, parce que c'est ce qui déterminera vraiment la date.

On reste attaché à ce qu'on livre. C'est la raison de fond derrière notre modèle d'abonnement plutôt qu'un forfait de projet. Si le coût réel se situe après la mise en ligne, la structure commerciale doit s'y trouver aussi.

On dit quand un projet est un test. Type Parts a quatre jours au moment d'écrire ces lignes et il est possible qu'il n'existe plus dans un an. C'est la catégorie du projet, et l'annoncer d'avance vaut mieux que de facturer un test au prix d'un système.

Si vous vous demandez dans quelle catégorie tombe le vôtre, c'est exactement la question par laquelle on commence. Écrivez-nous, ou faites d'abord passer un audit gratuit à votre site actuel pour voir ce qu'il en est aujourd'hui.