Vous avez un process métier qui vit entre Excel, mails et validations manuelles. Le sujet n'est pas de lancer un grand projet : c'est de sortir un premier outil interne utile avant de financer trois mois de flou.
Réponse courte : réalité pour un premier flux utile en production, en 15 jours ouvrés. Mythe pour une plateforme complète. Tout l'article tient dans cette distinction, et dans les conditions qui la rendent possible.
En informatique, le temps n'est plus seulement de l'argent. C'est du risque. Plus un projet d'outil métier reste longtemps sans utilisateur réel, plus il accumule des hypothèses : sur le besoin, le process, les données, l'adoption, la sécurité, le budget.
Le vieux réflexe consiste à répondre par plus de cadrage : ateliers, spécifications longues, comités, planning détaillé. Parfois, c'est utile. Souvent, sur un outil interne de complexité intermédiaire, cela repousse le moment où l'organisation apprend enfin quelque chose.
La promesse n'est pas de livrer un ERP, un SI complet ou une plateforme métier finale en deux semaines. La promesse sérieuse est plus précise : mettre en production, en 15 jours ouvrés, un premier flux utile, utilisable par de vrais utilisateurs, avec une base technique qui peut évoluer.
Un dossier créé. Une demande validée. Une facture contrôlée. Un reporting généré sans copier-coller. Un petit périmètre, mais réel. C'est lui qui transforme le projet en apprentissage.
Ces signaux ne prouvent pas qu'un prestataire est mauvais. Ils prouvent que le modèle n'est peut-être pas aligné avec votre besoin : démarrer vite, apprendre vite, limiter le budget exposé.
Si trois semaines partent dans des ateliers, des comptes rendus et une spec qui grossit, vous financez surtout de la coordination.
Un outil métier démarre mal quand chaque besoin devient critique. Le vrai sujet est de choisir le premier flux qui prouve la valeur.
Chef de projet, lead, développeurs, contrôle qualité : parfois nécessaire, parfois simple surcharge. Sur un premier périmètre, chaque relais ralentit le feedback.
Quand la production est traitée comme une cérémonie de clôture, le feedback terrain arrive trop tard. Le pipeline doit exister dès le départ.
Sur un build en 15 jours, un arbitrage bloqué 48 heures suffit à casser la dynamique. Le décideur doit être disponible, pas décoratif.
Le débat n'est pas moral. Une agence peut être pertinente. La régie peut être utile. Mais pour un outil métier qui doit démarrer vite, le modèle économique influence directement la vitesse, la clarté et la responsabilité.
| Modèle | Ce que vous achetez | Risque principal | Pertinent si... |
|---|---|---|---|
| Agence traditionnelle | Une équipe, des ateliers, un planning, beaucoup de coordination | Effet tunnel, spec qui vieillit, budget exposé aux changements | Projet large avec plusieurs chantiers parallèles et gouvernance lourde |
| Régie / TJM | Du temps disponible, pas un résultat | Le flou du scope, du délai et du budget reste entièrement à votre charge | Renfort identifié dans une équipe qui sait déjà piloter le produit |
| Build au forfait | Un premier résultat défini, livré pour un prix fixé | Le périmètre doit être arbitré franchement avant signature | Outil métier ciblé, besoin urgent, décisionnaire disponible |
| Fractional CTO | Des arbitrages seniors et une responsabilité dans la durée | Sans accès au décideur, le rôle se transforme en support premium | Projet à cadrer, prestataire à challenger, équipe ou produit à piloter |
Sur ce type d'outil interne, le build n'est souvent plus le goulot. Avec les bons outils, produire vite devient beaucoup plus accessible. Le risque se déplace : mauvais périmètre, mauvaise architecture, mauvais arbitrage.
L'IA ne comprend pas votre métier à votre place. Elle n'arbitre pas entre conformité, budget, dette technique et usage terrain. Une fois la décision posée, elle accélère l'écriture, les tests, la remise au propre du code et la documentation.
Ce qui accélère
Beaucoup d'outils internes n'ont plus besoin de six mois ou un an avant la première mise en production.
Ce qui change
Ce n'est plus seulement une problématique de délai ou de budget : les outils internes coûtent moins cher à produire qu'avant. Le coût de possession, lui, reste à piloter.
Ce que je vends
Dans mon cas, je préfère un forfait court et écrit à une régie ouverte quand le livrable peut être borné.
Le terrain idéal n'est pas le projet simple. C'est le projet assez concret pour qu'un premier flux utile puisse être isolé sans attendre que toute l'organisation se mette d'accord.
Remplacer des fichiers, emails et validations manuelles par un flux unique : demande, validation, suivi, reporting.
Structurer un outil de sourcing, de qualification fournisseur ou de validation interne sans attendre une refonte complète du SI.
Gérer des segments, droits ou règles de suivi sans exposer de données nominatives. HDS, RGPD santé, logs et traçabilité doivent entrer dès le premier jour.
Ce n'est plus un blocage en soi. Avec l'IA et le bon pilotage, le risque n'est pas l'absence de développeurs, mais l'absence d'arbitrage.
Exemple direction achats : quand le sujet est d'abord de consolider des fichiers Excel issus de plusieurs usines, le premier outil utile n'est pas un agent IA. Lire le cas sur la consolidation Excel achats.
Un bon démarrage n'est pas une course au code. C'est une séquence d'arbitrages qui évite de construire la mauvaise chose pendant trois mois.
Étape 1
Pas tout le produit. Le flux qui permettra à un utilisateur réel de faire une action utile : créer une demande, traiter un dossier, valider une facture.
Étape 2
Le forfait protège seulement si le scope est net : ce qui est dedans, ce qui est dehors, ce qui sera tranché plus tard. Il oblige à décider ce qui doit vraiment sortir.
Étape 3
Chaque changement doit pouvoir être testé et livré vite, sans recréer un cycle interminable de recette, validation et attente.
Étape 4
La version 1 sert à apprendre. Les utilisateurs révèlent les frictions que les ateliers sortent rarement.
Le forfait n'est pas magique. Il est pertinent quand le premier périmètre peut être écrit proprement. Si le risque est encore trop flou, mieux vaut commencer par un audit ou un cadrage Go/No-Go.
Utile avant signature : cartographier les risques, dire Go/No-Go, challenger un devis ou une architecture. 1 à 4 jours, 2 000 à 5 000 € HT.
Prix fixe pour un premier périmètre utile. Le prestataire porte son risque d'exécution, le client garde la maîtrise du budget.
Pertinent quand le sujet dépasse le premier build : roadmap, arbitrages, prestataires, dette technique, reprise ou montée d'équipe.
La régie facture des journées : sur un périmètre flou, chaque incertitude devient votre coût. Le forfait, lui, oblige à trancher ce qui doit vraiment sortir.
Dans mon modèle, un build d'outil métier se vend au forfait parce que le client doit savoir ce qu'il achète : un périmètre, un prix, un délai, une propriété du code. Si je dépasse sur mon estimation, à périmètre constant et client au rendez-vous, c'est mon problème. Si le besoin change, on l'écrit et on arbitre.
Piège 1
L'objectif des 15 jours n'est pas de tout livrer. C'est de sortir un premier périmètre sérieux, utilisable, qui déclenche du feedback réel.
Piège 2
Cas vécu : un cahier des charges généré par ChatGPT, plus de 30 pages, transmis tel quel et jamais vraiment relu. Ce n'est pas un cadrage, c'est un transfert de risque. Un bon cadrage tient souvent en moins de 5 pages : objectif, flux prioritaire, contraintes, exclusions et critères de succès. Dans mon cas, il démarre au premier call et je le finalise quand tous les éléments sont réunis, souvent après un aller-retour.
Piège 3
Le build rapide impose des choix rapides. Si le COMEX, le DG ou le sponsor métier n'est jamais joignable, la vitesse s'évapore.
Piège 4
Authentification, sauvegarde, logs, droits, déploiement : ces sujets ne sont pas une finition. Ils conditionnent la capacité à mettre en production.
Si votre projet d'outil métier met trois mois à commencer, ce n'est pas toujours parce qu'il est complexe. C'est parfois parce que le modèle choisi récompense la préparation, la coordination et l'élargissement du scope plus que la mise en production d'un premier résultat.
Le bon objectif n'est pas d'aller vite pour aller vite. C'est de réduire l'incertitude tôt : un flux réel, un utilisateur réel, une production réelle, puis des arbitrages sur du concret.
Six termes qui reviennent dans tout devis de développement d'outil métier. Les maîtriser vous évite d'acheter du temps en croyant acheter un résultat.
Oui, à trois conditions : un périmètre borné à un premier flux, un décideur qui tranche en 24 à 48 heures, des accès et dépendances SI clarifiés et provisionnés avant de démarrer. Non pour une plateforme complète. Les 15 jours ouvrés servent à mettre en production un flux réduit mais réel, sur une base technique qui peut évoluer.
Pas si le périmètre est réduit au lieu de réduire l'exigence. On coupe des fonctionnalités, pas la sécurité, la propriété du code, la traçabilité ou le déploiement.
Un vrai logiciel métier, si la mise en production fait partie du périmètre dès le premier jour : authentification, droits, sauvegardes, déploiement. Un prototype, si ces sujets sont reportés. La différence n'est pas la vitesse, c'est ce qu'on refuse de reporter.
Le TJM vend du temps. Sur un outil métier mal cadré, il vend surtout votre exposition au flou : scope, délai, budget. Pour démarrer vite, vous avez besoin d'un résultat, d'un prix et d'un périmètre. La régie reste utile quand une équipe interne sait déjà piloter le produit.
Ce n'est plus le blocage principal pour livrer. Avec l'IA et les bons outils, un profil senior peut cadrer, builder et documenter un premier outil. Le point critique devient l'accès au métier, au décideur et aux bons arbitrages. Et la suite se contractualise avec le build : qui exploite, qui corrige, qui répond en cas d'incident.
Vous décidez sur du réel : stabiliser, élargir le scope, corriger les irritants, brancher une intégration, renforcer la sécurité, passer en fractional CTO ou arrêter si l'hypothèse ne tient pas. C'est précisément l'intérêt.
Pour aller plus loin : le guide build vs buy pour décider quoi construire et quoi louer, et le guide pour faire valider l'outil par votre DSI si vous êtes en ETI.