Pourquoi votre logiciel métier doit être pensé comme un produit (et pas comme un projet)

Le syndrome du logiciel-projet : livré, oublié, obsolète

Vous avez peut-être déjà vécu ça. Une entreprise investit dans un outil interne. Six mois de développement, une livraison, une formation, et… plus rien. Le prestataire passe à un autre client. L'équipe interne remonte des bugs, des idées d'amélioration — personne ne répond. Au bout de 18 mois, le logiciel est contourné par des fichiers Excel parce qu'il ne suit plus l'évolution du métier.

Florent a vécu exactement l'inverse avec un projet récent. Un organisme de formation en présentiel jonglait entre 4 outils : émargement papier, Kahoot pour les quizz, PowerPoint pour les supports, Excel pour le suivi des apprenants. Un combat perdant au quotidien. Florent a développé une plateforme unique avec QR code pour l'émargement et quizz interactifs intégrés — pensée dès le départ en mode produit, avec des sprints courts et du feedback formateur à chaque itération. Résultat : un outil qui évolue à chaque session de formation, pas un logiciel figé qui sera obsolète dans 18 mois.

Approche projet vs approche produit : la différence fondamentale

L'approche projet, c'est : cahier des charges → développement → livraison → garantie de 3 mois → fin de la relation. C'est linéaire, borné dans le temps, et ça suppose que vous savez exactement ce dont vous aurez besoin dans 2 ans. Spoiler : vous ne le savez pas. Personne ne le sait.

L'approche produit, c'est : MVP → déploiement → mesure → feedback → itération → nouvelle version → mesure… en boucle. Le logiciel n'est jamais "fini". Il évolue avec votre métier, vos équipes, votre marché.

Les 4 piliers de l'approche produit

1. L'architecture modulaire

Un logiciel pensé produit est construit en modules indépendants. Le module facturation ne dépend pas du module planification. Vous pouvez faire évoluer l'un sans casser l'autre.

Concrètement, ça veut dire : une API bien définie entre chaque module, une base de données structurée avec des migrations propres, des tests automatisés qui vérifient que tout fonctionne après chaque modification. C'est plus de travail au démarrage, mais c'est ce qui fait qu'on peut encore faire évoluer un logiciel 5 ans après sa création.

2. Le cycle itératif court

Plutôt qu'un développement de 2 mois en chambre noire, on découpe en sprints de 2 semaines. À chaque fin de sprint, une version utilisable est livrée. L'équipe teste, fait des retours, et on ajuste.

On a développé un outil de gestion de parc locatif pour un bailleur social avec cette méthode. Au sprint 3, les gestionnaires nous ont dit que le workflow de signalement de panne était trop complexe — ils voulaient pouvoir signaler en 2 clics depuis leur téléphone. On a pivoté immédiatement. En mode projet classique, cette demande aurait coûté un avenant. En mode produit, c'était juste le sprint suivant.

3. La télémétrie et le feedback

Un logiciel-produit intègre du tracking d'usage dès le départ. Quels écrans sont utilisés ? Où les utilisateurs passent-ils du temps ? Quelles fonctionnalités sont ignorées ? Ces données orientent les évolutions.

Combiné à des sessions de feedback régulières (un call de 30 minutes par mois avec les utilisateurs clés), on obtient une roadmap basée sur la réalité terrain, pas sur des suppositions.

4. La dette technique maîtrisée

Tout logiciel accumule de la dette technique : raccourcis de code, dépendances obsolètes, contournements temporaires devenus permanents. L'approche produit prévoit des sprints de "nettoyage" réguliers pour maintenir la qualité du code.

C'est comme l'entretien d'un bâtiment : mieux vaut des petites réparations régulières qu'une rénovation complète tous les 5 ans. Le coût total est inférieur et le risque de panne majeure est quasi nul.

Ce que ça change dans la relation prestataire

L'approche produit transforme la relation avec votre prestataire. On passe d'un rapport client/fournisseur ponctuel à un partenariat technique continu. Chez Atenia, on appelle ça le "CTO externalisé" : on prend en charge la vision technique de votre outil, on anticipe les évolutions, on gère la roadmap avec vous.

Le modèle économique change aussi. Plutôt qu'un gros paiement initial puis des avenants imprévisibles, on fonctionne avec un forfait mensuel de 100 à 300 € qui couvre la maintenance, les évolutions et le support. Budget prévisible, valeur continue.

Comment évaluer si votre logiciel actuel est en mode projet ou produit

Posez-vous ces questions : quand est-ce que votre logiciel a été mis à jour pour la dernière fois ? Si la réponse est "il y a plus de 6 mois", vous êtes en mode projet.

Avez-vous accès à des statistiques d'usage ? Si non, personne ne mesure comment l'outil est réellement utilisé.

Vos utilisateurs ont-ils un canal pour remonter leurs besoins ? Si le seul moyen de demander une évolution est d'envoyer un mail qui reste sans réponse, c'est un problème.

Y a-t-il des tests automatisés ? Si chaque modification fait peur parce qu'on ne sait pas ce qu'elle va casser, l'architecture n'est pas pensée pour évoluer.