Le 7 août 2026, la DINUM a présenté une refonte de sa méthode d’évaluation des grands projets numériques de l’État. Sans être directement applicable aux entreprises privées, cette évolution met l’accent sur la valeur livrée, les usages et la capacité d’adaptation plutôt que sur le seul respect d’un budget et d’un calendrier. C’est précisément l’arbitrage auquel fait face un dirigeant avant de lancer un ERP, un CRM ou une application métier : faut-il tout spécifier à l’avance, faire cadrer le besoin par un tiers ou avancer avec un backlog évolutif ? La présentation de MAREVA Produit par la DINUM confirme ce déplacement vers un pilotage fondé sur les impacts.
Le cahier des charges reste utile, mais sa forme doit correspondre au niveau d’incertitude du projet. Un document trop vague empêche de comparer les offres ; un document trop rigide oblige à payer chaque découverte comme une modification.
Le choix qui se pose
La décision n’est pas « faut-il rédiger un cahier des charges ? », mais qui doit le produire, jusqu’à quel niveau de détail et avec quelle marge d’évolution.
Le document doit permettre à la direction de répondre à des questions concrètes :
- Quel résultat métier doit être obtenu ?
- Quelles activités et quelles entités sont dans le périmètre ?
- Quels cas d’usage seront effectivement livrés ?
- Quelles données devront être reprises, conservées ou supprimées ?
- Quelles interfaces devront fonctionner avec l’existant ?
- Qui validera les livrables et selon quels tests ?
- Que pourra récupérer l’entreprise si elle change de solution ou de prestataire ?
France Num rappelle qu’un cahier des charges sert à clarifier les objectifs, comparer les réponses et établir une référence commune avec le prestataire. Le principe reste pertinent au-delà des projets web abordés dans son dossier consacré à la construction d’un cahier des charges.
Avant d’ouvrir un modèle trouvé en ligne, désignez donc deux responsables : un sponsor habilité à arbitrer le budget et le périmètre, puis un référent métier capable de valider les règles de fonctionnement. Si personne n’a ce mandat, le problème n’est pas encore documentaire : il relève du pilotage, comme nous l’expliquons dans notre article sur les projets IT conduits sans DSI.
Les options en présence
Rédaction entièrement interne
Le référent métier consolide les demandes des équipes, décrit les fonctionnalités attendues et prépare les éléments transmis aux candidats.
Cette option conserve la maîtrise du besoin dans l’entreprise. Elle convient lorsque le processus est stable, bien documenté et porté par une personne qui connaît les utilisateurs, les exceptions et les données manipulées.
Le livrable minimum n’est pas une liste d’idées. Il doit comprendre le périmètre, les scénarios d’utilisation, les priorités, les contraintes, les critères de recette et les responsabilités internes.
Cadrage par une AMOA indépendante
Une assistance à maîtrise d’ouvrage — ou une direction de projet externe — organise les arbitrages, formalise les besoins et prépare un dossier de consultation utilisable par plusieurs intégrateurs.
L’indépendance est ici essentielle : la personne qui rédige ne doit pas avoir intérêt à imposer ensuite sa propre solution. Cette option est adaptée aux projets transverses, aux migrations de données, aux déploiements ERP ou CRM et aux entreprises qui ne disposent pas d’un responsable IT disponible.
L’AMOA ne remplace pas les métiers. Elle transforme leurs décisions en livrables vérifiables : cartographie des flux, fiches de besoins, matrice de données, exigences d’intégration, grille de sélection et stratégie de recette.
Phase de découverte menée par un prestataire pressenti
L’entreprise sélectionne un intégrateur pour réaliser une phase de cadrage payante avant de confirmer le déploiement complet.
Cette formule permet de confronter rapidement le besoin aux possibilités réelles d’une solution. Elle est pertinente lorsque la famille d’outils est déjà choisie, mais que les écarts entre le standard et les processus internes restent à mesurer.
Le contrat de découverte doit toutefois préciser que les livrables appartiennent à l’entreprise, qu’ils sont exploitables par un tiers et que leur validation ne déclenche pas automatiquement la commande suivante.
Backlog fonctionnel et réalisation itérative
Au lieu de figer toutes les fonctionnalités, l’entreprise définit un objectif produit, des règles non négociables et une liste ordonnée de besoins. Les éléments prioritaires sont détaillés au fur et à mesure.
Cette approche convient lorsque les utilisateurs doivent tester le futur fonctionnement avant de pouvoir exprimer précisément leur besoin. Les cycles doivent néanmoins produire un résultat utilisable et contrôlable. Le Scrum Guide officiel fixe, dans le cadre Scrum, des cycles d’une durée maximale d’un mois afin de permettre une inspection et une adaptation régulières.
Un backlog ne dispense donc ni d’un budget cible, ni d’exigences de sécurité, ni d’un périmètre initial. Il remplace le détail prématuré, pas les engagements.
Les critères qui comptent vraiment
| Option | Coût de cadrage | Délai avant consultation | Dépendance fournisseur | Compétences internes nécessaires | Réversibilité |
|---|---|---|---|---|---|
| Rédaction interne | Faible en dépenses externes, élevé en temps interne | Court si le besoin est déjà documenté | Faible au départ | Forte connaissance métier et capacité de formalisation | Bonne si les documents sont structurés et conservés |
| AMOA indépendante | Intermédiaire | Intermédiaire | Faible | Disponibilité des décideurs et référents métier | Élevée, car le dossier peut être remis à plusieurs candidats |
| Découverte par un prestataire | Intermédiaire, parfois déduite du projet suivant | Court à intermédiaire | Forte si les livrables restent liés à sa méthode | Capacité à challenger les propositions techniques | Variable selon le contrat et les formats livrés |
| Backlog itératif | Progressif | Très court avant le premier cycle | Variable selon l’architecture et l’équipe | Responsable métier disponible pour prioriser et valider | Bonne si le code, les données et la documentation restent transférables |
Le coût apparent du cadrage ne suffit pas pour arbitrer. Il faut également examiner le temps mobilisé par les équipes, le coût des modifications, les licences nécessaires aux tests, la reprise des données, le support après déploiement et l’abandon de l’ancien système.
Dans quel cas choisir quoi
Choisissez la rédaction interne si le projet concerne un processus stable, porté par un responsable identifié, avec des règles connues et des dépendances techniques limitées. Demandez au référent métier de produire des scénarios décrivant l’acteur, l’action, les données utilisées, le résultat attendu et le test de validation. La direction arbitre ensuite les priorités avant toute transmission aux fournisseurs.
Choisissez une AMOA indépendante si plusieurs directions doivent s’accorder, si le projet comporte une migration de données ou si un ERP et un CRM doivent échanger. Dans ce dernier cas, la matrice d’interfaces doit identifier les données de référence, le système maître, la fréquence des échanges et le traitement des erreurs. Notre guide sur la connexion entre CRM et ERP détaille les décisions à prendre avant de consulter les intégrateurs.
Choisissez une découverte menée par le prestataire lorsque vous avez déjà retenu un écosystème logiciel et que l’enjeu principal consiste à distinguer le paramétrage standard des développements spécifiques. Commandez cette étape séparément, avec un prix plafonné, une liste de livrables et une décision formelle de poursuite ou d’arrêt.
Choisissez le backlog itératif lorsque les usages vont évoluer au contact des utilisateurs ou lorsqu’un prototype est nécessaire pour trancher. Fixez néanmoins dès le départ les exigences qui ne peuvent pas attendre : droits d’accès, conservation des données, interfaces critiques, performances minimales, export et réversibilité.
Pour un déploiement ERP ou CRM, le scénario le plus robuste est souvent hybride : un socle cadré par une AMOA pour la consultation et les engagements contractuels, puis un backlog pour détailler progressivement le paramétrage et les écrans. Si l’entreprise ne dispose pas du rôle nécessaire pour maintenir cet arbitrage, la question d’une DSI à temps partagé doit être posée avant le lancement.
Les pièges de chaque option
Le piège de la rédaction interne consiste à reproduire l’organisation actuelle sans distinguer les règles réellement nécessaires des habitudes historiques. Pour le détecter, imposez à chaque demande un responsable, une justification métier et un test d’acceptation. Une exigence impossible à tester restera interprétable.
Le piège de l’AMOA est la production d’un document volumineux que personne dans l’entreprise ne s’approprie. Chaque partie doit être validée par un décideur nommé, et chaque exigence doit être reliée à un processus, un risque ou un objectif. L’AMOA organise la décision ; elle ne doit pas décider seule.
Le piège du cadrage par le futur intégrateur est la dépendance précoce. Vérifiez les formats de restitution, les droits d’utilisation, la liste des hypothèses et la possibilité de consulter un concurrent. Les propositions doivent séparer le standard, le paramétrage, les développements, les interfaces et les licences.
Le piège du backlog est l’emploi du mot « agile » pour différer les arbitrages de budget, de qualité ou de périmètre. Chaque cycle doit se terminer par une démonstration, des tests exécutés et une décision sur la suite. Une fonctionnalité commencée mais non testable ne constitue pas un résultat livré.
Enfin, aucune option ne doit laisser le RGPD et la sécurité dans une annexe générique. Lorsque le projet traite des données personnelles, les exigences doivent couvrir les finalités, les habilitations, la conservation, les incidents, les sous-traitants et la restitution des données. Les recommandations de la CNIL sur la gestion de la sous-traitance demandent notamment de contractualiser les responsabilités, les mesures de sécurité et les conditions de restitution ou de destruction. Le guide de l’ANSSI sur l’externalisation insiste également sur les exigences de transfert, d’exploitation et de réversibilité.
Comment nous procédons chez D1 Consulting
Notre offre de Direction de projet IT consiste à transformer les décisions de la direction et des métiers en un dossier que les prestataires peuvent chiffrer, que l’entreprise peut piloter et que les utilisateurs peuvent tester.
Notre méthode produit successivement :
- Une note d’arbitrage dirigeant, qui fixe le résultat attendu, le sponsor, les limites du projet et les décisions encore ouvertes.
- Un dossier fonctionnel, fondé sur les scénarios métier, les exceptions, les rôles et les données nécessaires, sans imposer prématurément une technologie.
- Une matrice des interfaces et des données, qui précise les systèmes sources, les responsabilités, les reprises et les contrôles.
- Une grille de consultation, commune à tous les candidats, qui sépare coûts de mise en œuvre, licences, maintenance, options et hypothèses.
- Une stratégie de recette, préparée avant la contractualisation, avec les tests bloquants, les preuves attendues et les responsabilités de validation.
- Un dispositif de gouvernance, indiquant qui arbitre une modification, comment elle est chiffrée et à quelles conditions elle entre dans le périmètre.
Nous adaptons ensuite le niveau de documentation : cahier des charges stabilisé pour un projet prévisible, backlog gouverné pour un produit évolutif, ou combinaison des deux pour un ERP, un CRM ou une application métier. Le livrable n’a pas pour objectif de tout prévoir, mais de rendre chaque engagement compréhensible, comparable et vérifiable.
👉 Réservez un diagnostic gratuit de 30 minutes pour choisir votre méthode de cadrage et identifier les livrables à produire avant de consulter vos prestataires.
