Un logiciel sur mesure, ça évolue comment une fois que ta boîte a changé de taille ?

Tu hésites à investir dans un logiciel sur mesure pour une raison qui n'a rien à voir avec le prix ou le délai : tu as peur qu'il devienne obsolète. Que dans dix-huit mois, quand ton équipe aura doublé, quand tu auras ajouté une offre, quand ton métier aura légèrement changé de forme, l'outil que tu viens de payer reste figé le jour de sa livraison — pendant qu'un SaaS générique, lui, continue de recevoir des mises à jour sans que tu aies à y penser. C'est une peur légitime. Et la réponse honnête, c'est : ça dépend entièrement de comment l'outil a été construit au départ.

Je construis des logiciels sur mesure, donc j'ai un parti pris — je te le dis sans détour plutôt que de faire semblant d'être neutre. Mais je vais t'expliquer précisément ce qui distingue un outil qui peut grandir avec toi d'un outil qui se fige, parce que la différence ne se voit pas sur la page d'accueil : elle se joue dans des choix invisibles pris avant même la première ligne de code.

Le vrai risque n'est pas le sur-mesure : c'est le sur-mesure mal pensé

Un logiciel sur mesure n'a, par nature, aucune raison d'être plus figé qu'un autre outil. C'est du code, une base de données, des écrans : rien de tout ça n'est gravé dans le marbre. Ce qui bloque un outil, ce n'est pas le fait qu'il ait été construit pour toi — c'est qu'il ait été construit sans marge, en pensant uniquement au périmètre du jour 1, sans jamais imaginer qu'un champ, un rôle ou un module puisse s'ajouter plus tard.

C'est là que la façon de travailler compte plus que l'outil en lui-même. Quand je conçois ton logiciel, je pense toujours à trois questions avant d'écrire le code : qu'est-ce qui va probablement changer dans un an, où faut-il laisser de la place, et qu'est-ce qu'on peut sciemment laisser de côté maintenant pour ne pas complexifier ce dont tu n'as pas encore besoin. Un outil bien conçu n'anticipe pas tout — ce serait un délire de sur-ingénierie qui ferait exploser ton budget pour des besoins hypothétiques. Il laisse simplement les bonnes portes ouvertes.

Ce que ça change concrètement, un an après la livraison

Prends un exemple simple : tu lances un outil de suivi client avec un seul type de compte, le tien. Six mois plus tard, tu embauches une première personne, et elle a besoin d'un accès limité — elle voit les dossiers en cours, pas la facturation. Si la base a été pensée avec des rôles dès le départ, même si un seul rôle existait au lancement, ajouter le deuxième prend quelques heures. Si elle ne l'a jamais été, il faut parfois rouvrir des pans entiers du code pour faire rentrer une notion qui n'existait pas — et ça coûte largement plus cher qu'anticiper cette marge dès le premier devis.

C'est la même logique pour à peu près tout : ajouter un nouveau statut de commande, brancher un second moyen de paiement, ouvrir l'outil à un partenaire externe, ou automatiser une étape qui se faisait encore à la main il y a un mois. Rien de tout ça n'est impossible avec du sur-mesure. Ce qui varie, c'est le temps et le prix que ça demande — et ce prix dépend directement des choix pris à la construction initiale.

Le prix d'une évolution : ni gratuit, ni un chantage

Il faut être honnête sur un point : faire évoluer un outil, ça a un coût. Personne ne travaille gratuitement, et je ne vais pas te vendre l'idée que ton logiciel va s'enrichir tout seul avec le temps. La question qui compte vraiment n'est pas « est-ce que ça coûtera quelque chose plus tard », mais « dans quelles conditions ».

• Chez moi, une évolution se chiffre exactement comme le projet initial : un devis clair, figé avant que je touche au clavier, jamais une facture qui tombe après coup.
• Tu n'es engagé sur rien : après les 30 jours de support inclus à la livraison, tu peux revenir me voir projet par projet, ou faire appel à quelqu'un d'autre — le code t'appartient.
• Un forfait mensuel d'hébergement et d'évolution existe pour ceux qui préfèrent une ligne fixe dans leur budget plutôt qu'un devis à chaque fois, mais ce n'est jamais imposé.

Compare ça à un SaaS : tu ne paies jamais de « devis d'évolution », c'est vrai — mais tu ne choisis pas non plus ce qui évolue. L'éditeur décide seul de sa feuille de route, et si la fonctionnalité dont tu as besoin ne rentre pas dans son plan produit, tu ne l'auras jamais, peu importe combien tu es prêt à payer. Avec du sur-mesure, l'inverse est vrai : ça a un prix, mais ce prix achète exactement ce dont toi tu as besoin, pas ce qu'un éditeur a décidé pour des milliers de clients en même temps.

R0 → 1, puis 1 → la suite

C'est là que le R0 → 1 prend tout son sens. La première livraison, ce n'est pas la ligne d'arrivée : c'est le moment où tu passes de rien — un tableur, un cahier, une tâche faite à la main — à un outil qui tourne vraiment. Une fois ce premier pas franchi, tu n'es plus jamais à zéro. Chaque évolution suivante part d'une base qui existe déjà, avec tes données, tes habitudes, ton vocabulaire déjà encodés dedans. C'est beaucoup plus facile d'aller de 1 à 2 que de rien à 1 — à condition que ce premier 1 ait été construit sans se tirer une balle dans le pied.

C'est pour ça que je ne vends jamais un projet comme un objet figé livré une fois pour toutes. Je le construis en pensant à ce qu'il pourrait devenir, sans jamais te faire payer aujourd'hui pour un besoin que tu n'as pas encore. La marge se prend dans la conception, pas dans le prix du jour 1.

Comment savoir si TON outil pourra suivre ? Les bonnes questions à poser

Avant de signer un devis, quel qu'il soit — chez moi ou ailleurs — pose ces questions directement :

• Est-ce que je suis propriétaire du code, ou je loue un accès à vie sans pouvoir le récupérer ?
• Si je veux ajouter une fonctionnalité dans six mois, ça se passe comment : un nouveau devis clair, ou une boîte noire où le prix se négocie sur le moment ?
• Le code est-il documenté, au point qu'un autre développeur pourrait reprendre le projet si besoin ?
• Est-ce que je suis coincé dans un abonnement obligatoire pour toucher à mon propre outil ?

Si les réponses te mettent mal à l'aise, c'est un signal — pas forcément que le sur-mesure n'est pas fait pour toi, mais que ce prestataire-là ne l'a peut-être pas pensé pour durer. La propriété du code et la clarté sur les évolutions futures sont les deux garde-fous qui protègent ton investissement sur la durée, bien plus que le prix affiché au premier devis.

Si tu veux voir comment je m'y prends concrètement, l'offre détaille le prix, la méthode et la garantie « ta maquette en 7 jours ou tu ne dois rien ». Et si tu hésites encore entre agence et sur-mesure avant même de penser aux évolutions futures, ce comparatif honnête pose les bases.