Combien de temps prend vraiment un projet de digitalisation ?
Des durées réalistes par type de projet, et pourquoi la partie technique n'est presque jamais ce qui prend le plus de temps.
En résumé : pour une PME, comptez trois à six mois entre le diagnostic et la mise en production du premier périmètre utile — et une durée comparable pour que l'usage s'installe réellement. Méfiez-vous de toute estimation nettement plus courte : ce qui prend du temps n'est pas le développement, c'est la décision, la donnée et l'adoption. Ces trois postes sont chez vous, pas chez le prestataire.
Des ordres de grandeur
- Cadrage et chiffrage — deux à quatre semaines. C'est court, et c'est ce qui détermine tout le reste.
- Digitalisation d'un processus ciblé (devis, commandes, interventions) — deux à quatre mois.
- Outil de gestion couvrant plusieurs processus — quatre à huit mois pour un premier périmètre en production, plus si la migration de données est lourde.
- Reprise d'un projet en échec — comptez d'abord deux à trois semaines d'état des lieux avant toute estimation. Estimer sans cet état des lieux, c'est répéter l'erreur qui a causé l'échec.
Pourquoi ce n'est pas la technique qui ralentit
Les décisions
Le prestataire pose une question ; la réponse demande de trancher entre deux services. Chaque arbitrage qui traîne une semaine ajoute une semaine — et ces semaines ne se rattrapent pas, elles s'additionnent.
Les données
Personne ne sait dans quel état sont réellement les données avant de commencer à les migrer. Le nettoyage est presque toujours plus long que prévu, et c'est un travail que vos équipes doivent faire : elles seules savent quelle version est la bonne.
L'adoption
Un outil livré n'est pas un outil utilisé. La période où les anciennes habitudes coexistent avec les nouvelles est la plus fragile du projet, et c'est celle qu'on planifie le moins.
Ce qui accélère réellement
- Un périmètre plus petit. Un premier lot restreint mis en production vaut mieux qu'un périmètre complet livré six mois plus tard — vous apprenez avec de vrais utilisateurs.
- Un décideur unique côté métier, disponible et légitime.
- Le nettoyage des données commencé avant le début du développement, pas pendant.
- Des critères de recette écrits au départ, ce qui évite la négociation de fin de projet.
Le calendrier à refuser
Un planning sans marge, sans période de recette, et sans temps prévu pour vos équipes n'est pas un planning optimiste : c'est un planning qui reporte le dépassement au moment où il coûtera le plus cher à annoncer. Un prestataire qui accepte votre délai sans discuter ne l'a pas évalué.
Durées réellement observées sur mes propres missions
Plutôt que des fourchettes théoriques, voici des durées que j'ai mesurées. Elles ne sont pas des promesses pour votre projet, mais des ordres de grandeur vérifiables.
- Un cahier des charges complet : dix jours ouvrés (entretien de cadrage, rédaction, deux tours de relecture, estimation de charge).
- Un audit de risque projet : dix jours ouvrés, de l'accès au code à la restitution de 90 minutes.
- Une première version d'un outil interne ciblé : neuf commits en quatre jours pour la v1 d'un résumeur de réunions par IA, ce qui montre qu'un périmètre étroit et bien cadré se livre vite.
- Un moteur de sourcing B2B complexe : environ quatre semaines (29 commits) pour la couche de collecte et d'audit, la couche d'envoi automatique restant volontairement bloquée tant que la validation manuelle n'a pas produit de résultats.
- Passer un outil mono-client à un vrai SaaS multi-clients : un plan en six phases et soixante tâches, toutes terminées, pour une plateforme de gestion de garages.
Ce que ces chiffres montrent
Les durées les plus courtes correspondent à des périmètres écrits et étroits. Les plus longues correspondent à des changements de nature du produit (multi-clients, intégration d'un système existant). La technique n'est presque jamais le poste le plus lourd : ce sont la décision, la donnée et l'adoption, comme expliqué plus haut.
Réduire le risque de dérapage de délai
- Faites écrire le périmètre et les critères d'acceptation avant de demander une estimation.
- Faites chiffrer la migration de données séparément.
- Nommez une personne qui tranche les questions du prestataire sous deux jours.
Pour cadrer d'abord, voir l'offre cahier des charges et spécifications.
Articles similaires
Notes
Audit de code : ce qu’il vérifie et ce qui détermine son prix
Ce que couvre un audit de code utile, des constats réels tirés de projets en production, ce qui fait varier le prix et cinq questions à poser à tout auditeur.
Notes
Modèle de cahier des charges pour une application mobile
Le modèle en neuf rubriques que j’utilise pour une application mobile, avec des critères d’acceptation testables et les erreurs à éviter.
Notes
Comment évaluer le travail d’une agence de développement sans lire le code
Noter chaque livrable face à des critères écrits, tester côté métier, repérer les cinq signaux d’alerte et vérifier ce qui est entre vos mains.
Newsletter
Recevez mes prochains articles directement dans votre boîte mail.