Réponse courte : c'est une réalité pour un premier flux utile en production, en 15 jours ouvrés, et un mythe pour une plateforme complète. Tout l'article tient dans cette distinction, et dans les conditions qui la rendent possible.
Plus votre 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. En informatique, le temps n'est plus seulement de l'argent, c'est du risque.
Le vieux réflexe consiste à répondre par plus de cadrage : ateliers, spécifications longues, comités, planning détaillé. C'est parfois utile, mais souvent, sur un outil interne de complexité intermédiaire, ce cadrage repousse le moment où l'organisation apprend enfin quelque chose.
Ce que veut vraiment dire « 15 jours »
La promesse n'est pas de livrer un ERP, un SI complet ou une plateforme métier finale en 2 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.
Choisissez ce premier flux parmi les gestes concrets du terrain, comme ces 4 exemples :
- un dossier créé ;
- une demande validée ;
- une facture contrôlée ;
- un reporting généré sans copier-coller.
Le périmètre est petit mais réel, et c'est lui qui transforme le projet en apprentissage.
Les signaux que la méthode part de travers
Repérez les 5 signaux suivants dès les premiers échanges sur votre projet. Ils ne prouvent pas qu'un prestataire est mauvais, mais que le modèle n'est peut-être pas aligné avec votre besoin : démarrer vite, apprendre vite, limiter le budget exposé.
- 01
Le cadrage dure plus longtemps que le premier build
Si 3 semaines partent dans des ateliers, des comptes rendus et une spec qui grossit, vous financez surtout de la coordination.
- 02
Personne ne sait dire ce qui doit partir en version 1
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.
- 03
Votre prestataire parle d'équipe avant de parler de risque
Chef de projet, lead, développeurs, contrôle qualité : cette équipe est parfois nécessaire, parfois simple surcharge, et sur un premier périmètre chaque relais ralentit le feedback.
- 04
Le déploiement arrive à la fin
Quand la production est traitée comme une cérémonie de clôture, le feedback terrain arrive trop tard. Le pipeline de mise en production doit donc exister dès le départ.
- 05
Le sponsor métier répond quand il peut
Sur un build en 15 jours, un arbitrage bloqué 48 heures suffit à casser la dynamique. Le décideur doit être disponible, pas décoratif.
Agence, régie, forfait, fractional CTO : ce que vous achetez vraiment
Comparez les 4 modèles sur ce que vous achetez réellement et sur leur risque principal. Le débat n'est pas moral : une agence peut être pertinente et 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é.
Agence traditionnelle
- Ce que vous achetez
- Une équipe, des ateliers, un planning, beaucoup de coordination
- Risque principal
- Effet tunnel, spec qui vieillit, budget exposé aux changements
- Pertinent si…
- Projet large avec plusieurs chantiers parallèles et gouvernance lourde
Régie au prix par jour
Le prestataire facture le temps passé, au prix par jour. Le client pilote le travail et porte le risque de dérive.
- Ce que vous achetez
- Du temps disponible, pas un résultat
- Risque principal
- Le flou du scope, du délai et du budget reste entièrement à votre charge
- Pertinent si…
- Renfort identifié dans une équipe qui sait déjà piloter le produit
Build au forfait
Un résultat défini, livré pour un prix fixé avant de commencer. Le prestataire porte le risque d'exécution, à condition d'un périmètre écrit, avec ses exclusions.
- Ce que vous achetez
- Un premier résultat défini, livré pour un prix fixé
- Risque principal
- Le périmètre doit être arbitré franchement avant l'acceptation du devis
- Pertinent si…
- Outil métier ciblé, besoin urgent, décisionnaire disponible
Fractional CTO
Un directeur technique senior à temps partagé, engagé dans la durée.
- Ce que vous achetez
- Des arbitrages seniors et une responsabilité dans la durée
- Risque principal
- Sans accès au décideur, le rôle se transforme en support premium
- Pertinent si…
- Projet à cadrer, prestataire à challenger, équipe ou produit à piloter
Développement rapide d'un logiciel métier : ce que change l'IA
Sur ce type d'outil interne, le build n'est souvent plus le goulot. Avec les bons outils, produire vite devient beaucoup plus accessible, et le risque se déplace : mauvais périmètre, mauvaise architecture, mauvais arbitrage.
L'IA ne comprend pas votre métier à votre place, et 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.
Beaucoup d'outils internes n'ont plus besoin de 6 mois ou un an avant la première mise en production.
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.
Dans mon cas, je préfère un forfait court et écrit à une régie ouverte quand le livrable peut être borné.
Les cas où cette approche marche bien
Votre projet s'y prête s'il est assez concret pour isoler un premier flux utile sans attendre que toute l'organisation se mette d'accord. Le terrain idéal n'est pas le projet simple.
Opérations multi-sites
Remplacer des fichiers, emails et validations manuelles par un flux unique : demande, validation, suivi, reporting.
Direction achats
Structurer un outil de sourcing, de qualification fournisseur ou de validation interne sans attendre une refonte complète du SI.
Santé et données sensibles
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.
Structure sans équipe tech
L'absence d'équipe tech 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. Le cas sur la consolidation Excel achats le montre en détail.
La méthode : démarrer petit, mais en production
Pour bien démarrer votre projet, suivez une séquence d'arbitrages plutôt qu'une course au code : elle évite de construire la mauvaise chose pendant 3 mois.
Décider du flux qui mérite 15 jours
On ne vise pas tout le produit, mais le flux qui permettra à un utilisateur réel de faire une action utile : créer une demande, traiter un dossier, valider une facture.
Écrire un forfait sur ce flux, pas sur un rêve de plateforme
Le forfait protège seulement si le scope, c'est-à-dire le périmètre du projet, est net : ce qui est dedans, ce qui est dehors, ce qui sera tranché plus tard. Il oblige aussi chacun à décider ce qui doit vraiment sortir.
Prévoir la mise en ligne dès le début
Chaque changement doit pouvoir être testé et livré vite, sans recréer un cycle interminable de recette, validation et attente.
Faire tester le terrain avant d'élargir
La version 1 sert à apprendre : les utilisateurs révèlent les frictions que les ateliers sortent rarement.
Budget : le bon modèle dépend du risque
Choisissez le forfait quand le premier périmètre peut être écrit proprement : il n'est pas magique. Si le risque est encore trop flou, mieux vaut commencer par un audit ou un cadrage Go/No-Go.
Audit court
Utile avant de lancer le build : cartographier les risques, dire Go/No-Go, challenger un devis ou une architecture. Comptez 1 à 4 jours, pour 2 000 à 5 000 € HT.
Build initial au forfait
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.
Fractional CTO
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.
Les 5 questions à poser avant d'accepter un devis
- Qui écrit réellement le code ?
- Que pouvez-vous mettre en production dans les 15 premiers jours ?
- Combien de temps entre une modification validée et sa mise en production ?
- À qui appartient le code, les dépôts, les accès et l'hébergement ?
- Quel arbitrage réduirait le plus le risque dès maintenant ?
Les pièges à éviter
Confondre premier jet et produit complet
L'objectif des 15 jours n'est pas de tout livrer, mais de sortir un premier périmètre sérieux, utilisable, qui déclenche du feedback réel.
Envoyer un cahier des charges que personne n'a relu
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. Avec moi, le cadrage démarre au premier call et se finalise quand tous les éléments sont réunis, souvent après un aller-retour.
Démarrer sans accès au décideur
Le build rapide impose des choix rapides : si le comité exécutif, le DG ou le sponsor métier n'est jamais joignable, la vitesse s'évapore.
Reporter sécurité et exploitation
Authentification, sauvegarde, logs, droits, déploiement : ces sujets ne sont pas une finition, ils conditionnent la capacité à mettre en production.
Auteur de l'article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes sur l'outil métier en 15 jours
Est-ce réaliste de livrer un outil métier en 15 jours ?
Oui, à 3 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. Pour une plateforme complète, c'est non : les 15 jours ouvrés servent à mettre en production un flux réduit mais réel, sur une base technique qui peut évoluer.
Le build rapide sacrifie-t-il la qualité ?
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 développement rapide donne-t-il un vrai logiciel métier ou un prototype ?
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.
Pourquoi la régie au prix par jour pose-t-elle problème sur ce type de projet ?
La régie au prix par jour vend du temps : sur un outil métier mal cadré, elle vend surtout votre exposition au flou, sur le scope, le délai et le 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.
Quelle différence entre une régie et un forfait ?
En régie, le prestataire facture le temps passé, au prix par jour : vous pilotez le travail et portez le risque de dérive. Au forfait, il livre un résultat défini pour un prix fixé avant de commencer et porte le risque d'exécution. La condition du forfait est un périmètre écrit, avec ses exclusions.
Et si nous n'avons aucune équipe technique ?
L'absence d'équipe technique 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.
Que se passe-t-il après les 15 jours ?
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.