Dossier outil interne
Build vs buy, ROI, méthodologie, sécurité, adoption : tout ce qu'un dirigeant de PME doit trancher avant, pendant et après la construction d'un outil interne sur mesure.
À 30, 50 ou 100 collaborateurs, presque toutes les PME atteignent le même point d'inflexion : les SaaS choisis au démarrage ne tiennent plus la charge, Excel pète, et les équipes passent plus de temps à recopier des données qu'à produire de la valeur. La tentation est forte d'empiler un SaaS de plus, ou de bricoler une intégration Zapier qui résiste deux trimestres.
L'alternative — construire un outil interne sur mesure — fait peur pour de bonnes raisons : on a tous entendu parler d'un projet à 12 mois qui s'est terminé en plan B, ou d'un dev freelance disparu avec le code source. Mais en 2026, le rapport coût/risque a changé : un MVP utilisable en 8 semaines est devenu la norme, le budget tient sur un trimestre de SaaS, et les briques IA permettent de couvrir des cas d'usage qui auraient pris 6 mois à coder à la main il y a deux ans.
Ce dossier rassemble les questions que se posent les dirigeants avant de signer : quand vraiment build plutôt qu'acheter, comment calculer un ROI honnête, par où commencer un cahier des charges, comment éviter le rejet de l'équipe, et ce que ça coûte une fois en production. Pas de promesse magique — juste les arbitrages réels que nous voyons en mission.
La règle utile n'est pas "build = noble, buy = lâche". C'est : achetez tout ce qui est commodité (paie, signature électronique, antivirus), construisez ce qui touche au cœur métier — le flux qui fait que votre PME gagne ou perd de l'argent. Si vous payez 800 €/mois pour un SaaS dont vous utilisez 20 %, vous ne payez pas le logiciel : vous payez les fonctions qu'il a fallu compresser pour vendre à votre voisin et au voisin de votre voisin.
Le signal d'alerte concret : votre équipe maintient un ou plusieurs Sheets en parallèle du SaaS pour combler ses trous. C'est le coût caché — temps de double saisie, erreurs, fragilité. À ce stade, un outil interne devient rentable en 18 à 24 mois, pas en 5 ans.
Un calcul honnête additionne quatre lignes : (1) heures économisées par les équipes, valorisées à leur coût chargé, (2) erreurs et ressaisies évitées, (3) abonnements SaaS résiliés ou non engagés, (4) ouverture de capacité — combien de clients ou de volume en plus, à effectif constant. Sur nos missions, ces 4 lignes additionnées font tourner un MVP autour de 6-12 mois, le code complet autour de 18-24 mois.
Ce que ça ne couvre pas : la marge commerciale d'avoir un outil que vos concurrents n'ont pas. C'est réel mais difficile à chiffrer — on le note séparément.
MVP d'abord, toujours. Un MVP utile = le sous-flux qui fait gagner le plus de temps à 80 % des utilisateurs visés, livré en 6 à 10 semaines. Le piège classique : essayer de remplacer Sage + HubSpot + Notion + Excel d'un coup. Ça finit en projet à 12 mois et zéro adoption.
Le bon cahier des charges tient en 4 pages : le flux concret jour 1, les 3 user stories qui débloquent immédiatement, la liste des intégrations indispensables (ERP, signature, banque), et ce qui sort explicitement du scope V1.
Trois questions à imposer dès le devis : qui possède le code (réponse correcte : vous), où sont hébergées les données (idéalement votre cloud ou un cloud souverain), et comment se passe une fin de contrat (réponse : transfert du repo et de la doc, point). Les studios sérieux acceptent ces clauses sans broncher. Les autres vous vendent un SaaS déguisé.
Pour la sécurité au sens IT (RGPD, audit, accès), un outil interne n'est ni mieux ni moins bien qu'un SaaS — il est ce que vous décidez d'en faire. La différence : vous voyez le code, donc vous pouvez prouver ce qu'il fait.
Un outil parfait que personne n'utilise vaut zéro. Les leviers qui marchent : (1) impliquer un "power user" de l'équipe dès la phase de specs, (2) livrer un V0 cliquable rapidement même imparfait, (3) prévoir 1-2 jours de formation par groupe, pas un PDF, (4) tuer l'ancien outil — tant qu'Excel reste branché, l'équipe y retournera.
Et accepter qu'un mois après le go-live, on ajuste : ce qui marchait sur papier ne marche jamais à 100 % en production.
Pour un MVP utilisable (le sous-flux le plus critique, en production avec 5-15 utilisateurs), comptez entre 25 000 et 80 000 € selon la complexité métier et les intégrations. Le code complet d'un outil de gestion qui remplace 3 à 5 SaaS tourne entre 80 000 et 200 000 €. Cela inclut les specs, le développement, la mise en production et la formation. La maintenance annuelle représente ensuite 15 à 25 % du build initial.
Sur nos missions, le retour sur investissement se concrétise entre 6 et 24 mois. Un MVP qui élimine 10 à 15 heures de saisie hebdomadaire pour une équipe de 10 personnes paie son build en moins d'un an. Le calcul à faire : (heures économisées × coût horaire chargé) + (abonnements SaaS supprimés) + (erreurs évitées) + (capacité ouverte à effectif constant).
Cinq signaux convergents : (1) votre équipe maintient des Sheets parallèles pour combler les trous des SaaS, (2) vous payez plusieurs centaines d'euros par mois pour des fonctions utilisées à 20 %, (3) chaque nouvelle exception métier nécessite un workaround manuel, (4) les intégrations Zapier/Make multiplient les bugs, (5) onboarder un collaborateur prend plus de 2 semaines à cause de l'éparpillement des outils.
Un MVP utilisable en production : 6 à 10 semaines selon la complexité. Le code complet (toutes les fonctions cibles, intégrations comptables, automatisations) : 4 à 8 mois. Les projets qui durent plus de 12 mois échouent statistiquement plus que les autres — c'est le signal d'un scope mal cadré, pas d'une ambition forte.
Le no-code (Airtable, Bubble, Notion) tient pour valider une idée à très petite échelle ou pour des process périphériques. En production avec plus de 10 utilisateurs et des règles métier réelles, il craque : limites de performance, impossibilité de versionner, dépendance forte à l'éditeur. Le code sur mesure devient pertinent dès que l'outil devient critique pour le business — typiquement quand le bug d'un dimanche soir vous coûte de l'argent le lundi matin.
Quatre leviers prouvés : (1) impliquer un "power user" terrain dès les specs, pas après, (2) livrer un V0 cliquable rapidement, même imparfait, pour récolter du feedback réel, (3) prévoir 1 à 2 jours de formation en présentiel par groupe, pas un manuel PDF, (4) couper l'ancien outil — tant qu'il reste accessible, l'équipe y retournera. Et accepter d'itérer 4-6 semaines après le go-live.
Vous. C'est non négociable et doit être écrit dans le contrat : transfert intégral du code source, de la documentation technique et des accès dès la livraison. Les studios sérieux acceptent ces clauses sans discussion. Si on vous vend un "SaaS sur mesure" hébergé chez le studio sans transfert possible, c'est un piège : vous payez un développement spécifique sans en garder la propriété, donc sans pouvoir changer de prestataire ni internaliser plus tard.
On a livré 30+ outils internes. Voir le format qui colle au vôtre.
Nous utilisons des cookies de mesure d'audience (Google Analytics) pour comprendre comment notre site est utilisé. Vous pouvez accepter ou refuser à tout moment. En savoir plus.