Ce qui fait dérailler un projet n'est jamais ce qu'on croit au départ
La plupart des projets digitaux qui déraillent ne déraillent pas à cause d'un mauvais développeur ou d'un outil inadapté. Ils déraillent parce que personne n'a pris le temps de répondre à deux questions simples : quel est le problème réel ? et qu'est-ce qu'on considère comme un succès ?
La note de cadrage est le document qui force à répondre à ces questions, et à documenter les réponses de façon que tout le monde les comprenne de la même manière. Pas seulement le CTO et le directeur général. Aussi le commercial qui ressaisit des données depuis dix ans, la responsable ADV qui a inventé ses propres conventions Excel, et le prestataire technique qui n'a jamais mis les pieds dans votre secteur.
Mais attention : une note de cadrage mal structurée est souvent pire que pas de note du tout. Elle crée une fausse sécurité. On "a un document", donc on pense qu'on est alignés. Les vrais désaccords restent enfouis. Et ils ressortent au moment le plus coûteux : en plein développement, ou pire, en production.
Ce guide présente la structure en 12 sections qu'on utilise chez Leando sur tous nos projets. Elle est issue de dizaines de missions sur des PME industrielles, des startups et des grands groupes. Chaque section a un rôle précis. On vous explique ce rôle, ce qu'on y met, et l'erreur classique associée.
Le piège numéro un : vous avez déjà la solution avant de comprendre le problème
Le piège numéro un dans la rédaction d'une note de cadrage, c'est de partir de ce qu'on veut construire (la liste de fonctionnalités, le nom de l'outil, les modules souhaités) plutôt que de partir de ce qui se passe réellement dans l'entreprise.
Résultat : une liste de vœux déguisée en document structuré. Elle ressemble à une note de cadrage. Elle a des sections, des titres, des tableaux. Mais elle ne documente pas les processus réels, les règles métier implicites, les contraintes d'intégration. Elle ne dit pas pourquoi ces fonctionnalités et pas d'autres. Et quand le développeur commence à travailler, il découvre que ce qui était "évident" pour tout le monde ne l'était pas pour lui.
« On est venu non plus avec des specs, avec un cahier des charges, mais avec une compréhension de leur quotidien et de leurs objets métier. »
La première étape avant de rédiger quoi que ce soit, c'est donc d'aller sur le terrain. Interviews des utilisateurs clés (pas seulement les managers), observation des processus en situation réelle, cartographie des flux d'information. Cette phase prend 2 à 5 jours selon la complexité. Elle est non-négociable.
La structure que nous appliquons sur tous nos projets, section par section
Section 1 — Contexte et enjeux business
Cette section répond à la question : pourquoi ce projet maintenant ? Elle n'est pas là pour présenter l'entreprise (ça, tout le monde le sait), mais pour expliquer le déclencheur du projet : la contrainte ou l'opportunité qui rend le statu quo insupportable.
Erreur classique : écrire une introduction générique sur "la transformation digitale" ou "les enjeux de compétitivité". Ce n'est pas du contexte, c'est du remplissage. Un bon contexte est daté, chiffré, et identifie une tension réelle : "depuis l'embauche du nouveau RAF en janvier, on a diagnostiqué que 30% du temps de l'équipe ADV est consacré à la ressaisie entre l'ERP et Excel."
Section 2 — Problèmes à résoudre (problématique)
C'est la section la plus importante et souvent la moins bien rédigée. Elle doit nommer les problèmes concrets, pas les symptômes généraux. Pas "notre SI est dépassé", mais "nos commerciaux créent manuellement 45 devis par mois dans un fichier Word, chaque devis prend 1h30, il y a 3 erreurs par semaine qui bloquent la facturation."
La règle : chaque problème doit être vérifiable. Si on ne peut pas le mesurer ou l'observer, c'est une opinion, pas un problème.
Section 3 — Objectifs et critères de succès
Les objectifs répondent à "où veut-on aller ?" Les critères de succès répondent à "comment sait-on qu'on est arrivés ?" Ce sont deux questions distinctes qu'on confond souvent.
Un bon critère de succès est mesurable et daté. Pas "améliorer la gestion des devis", mais "en 6 mois, le délai moyen de génération d'un devis passe de 1h30 à 15 minutes, avec 0 erreur de saisie détectée en production."
Section 4 — Périmètre (in scope / out of scope)
Ce que la note de cadrage doit construire dans l'esprit de toutes les parties prenantes : une frontière claire. Qu'est-ce qu'on fait ? Qu'est-ce qu'on ne fait pas dans cette version ? Quelles décisions sont reportées à une version 2 ?
L'out of scope est aussi important que l'in scope. Il protège le projet du scope creep : l'accumulation de demandes non planifiées qui retardent les livraisons et épuisent les budgets.
Section 5 — Utilisateurs et parties prenantes
Qui utilise le système ? Qui décide ? Qui valide ? Qui est impacté sans utiliser directement ? Cette cartographie des acteurs est indispensable : elle révèle les jeux de pouvoir et les résistances potentielles, informations cruciales pour planifier le changement.
Format recommandé : tableau avec colonnes Rôle / Profil / Fréquence d'utilisation / Enjeu / Niveau d'implication souhaité dans le projet.
Vous êtes en train de démarrer un projet et vous ne savez pas par où commencer ?
En 30 minutes, on peut cartographier votre situation et vous dire si une phase de cadrage structurée vous ferait gagner du temps, et combien.
Parler à Donatien →Section 6 — Processus métier cibles
C'est la section technique la plus dense, et la plus sous-estimée. Elle cartographie les processus tels qu'ils devraient fonctionner après le projet, en distinguant clairement de leur état actuel. Elle n'est pas une liste de fonctionnalités : c'est une description des flux d'information, des règles de gestion, des cas d'usage critiques, des exceptions.
Sur le projet BKW Énergie France, cette section a pris 3 jours à construire, parce que les règles métier sur l'énergie (TURPE, Enedis, soutirage/injection) étaient implicites, jamais documentées. C'est ce travail de surface qui a permis d'éviter des erreurs d'architecture coûteuses.
« On parle d'énergie, de soutirage, d'injection, d'Enedis, de TURPE — plein de vocabulaires techniques qui impliquent des règles métier techniques. La force, ça a été de se projeter dans leur métier tout en gardant un regard extérieur pour poser les bonnes questions. »
Section 7 — Règles métier et contraintes fonctionnelles
Les règles métier sont les lois non écrites qui gouvernent votre activité. Elles ne sont jamais dans les specs, rarement dans les procédures internes. Elles sont dans les têtes des personnes qui font le travail depuis 5 ou 10 ans.
Cette section doit les extraire et les formaliser. Exemples : "un devis ne peut pas être envoyé sans validation du directeur commercial si le montant dépasse 15K€", "un lot de calibration est refusé si plus de 3% des pièces échouent au contrôle", "une commande urgente peut bypasser le processus habituel si elle est taguée prioritaire dans l'ERP". Ces règles doivent être connues du prestataire technique avant qu'il écrive une seule ligne de code.
Section 8 — Contraintes techniques et intégrations
Quels systèmes existent déjà ? Lesquels doivent être conservés, intégrés, remplacés ? Quelle infrastructure ? Quelles contraintes de sécurité, RGPD, conformité ? Quelles APIs disponibles ? Quelles versions de logiciels contraintes par des licences ou des prestataires existants ?
Cette section protège contre les mauvaises surprises en développement. Un prestataire qui découvre en phase de développement que l'ERP existant n'a pas d'API sortante perdra plusieurs semaines et fera perdre du budget.
Section 9 — Hypothèses et dépendances
Qu'est-ce qu'on suppose vrai pour que ce projet fonctionne ? Que les données dans l'ERP sont fiables à 90% ? Que l'équipe sera disponible pour les recettes ? Que la migration des données historiques est réalisable en moins d'un mois ?
Documenter ces hypothèses, c'est créer des points de vérification. Si une hypothèse s'avère fausse en cours de projet, on le sait immédiatement et on peut ajuster, au lieu de découvrir le problème en production.
Section 10 — Risques identifiés et mitigations
Les risques ne sont pas des catastrophes improbables. Ce sont les événements qui ralentiraient ou compromettraient le projet si on ne les anticipe pas : manque de disponibilité des utilisateurs clés, données sources de mauvaise qualité, résistances organisationnelles, dépendances sur des tiers.
Format recommandé : tableau Risque / Probabilité / Impact / Mitigation prévue. Pas besoin de 20 risques. 5 à 8 risques bien documentés suffisent.
Section 11 — Budget, ressources et organisation
Qui fait quoi ? Côté client : qui est le sponsor, qui est le chef de projet interne, qui sont les référents métier disponibles pour les recettes ? Côté prestataire : quelle équipe, quel rythme de livraison, quels points de synchronisation ?
Le budget n'a pas besoin d'être précis à ce stade (c'est le rôle du devis), mais l'ordre de grandeur et les phases doivent être clairs. Un projet en deux phases (R&D + industrialisation) n'a pas le même modèle d'engagement qu'un projet forfaitaire unique.
Section 12 — Plan de déploiement et critères de recette
Comment va-t-on livrer ? En big bang ou en déploiement progressif ? Qui valide ? Sur quels critères ? Comment gère-t-on le run pendant la transition ?
Cette section est souvent la dernière rédigée mais elle devrait être pensée en premier : la façon dont on prévoit de livrer conditionne souvent le découpage technique et fonctionnel. Un déploiement progressif par service oblige à concevoir des fonctionnalités indépendantes. Un big bang implique un plan de migration plus lourd.
Chez Chanel, deux prestataires avaient échoué. Le cadrage avait été sauté deux fois.
Quand Leando a repris le projet Chanel, le projet était arrêté depuis 18 mois. Deux prestataires différents avaient essayé de le faire avancer. L'équipe interne avait perdu confiance. Le sponsor était épuisé.
La première action : reprendre le cadrage depuis zéro. Pas pour refaire ce que les précédents prestataires avaient fait — mais pour comprendre pourquoi ça n'avait pas fonctionné. En deux semaines d'entretiens, on a identifié que les processus métier cibles n'avaient jamais été correctement documentés (section 6). Chaque prestataire avait travaillé depuis ses propres hypothèses sur le fonctionnement interne. Ces hypothèses étaient fausses — mais personne ne l'avait dit clairement.
Avec un cadrage complet en 12 sections (règles métier implicites et contraintes d'intégration incluses), le projet a pu démarrer sur des bases solides. Résultat : livré en 8 mois, avec un mois d'avance sur le planning.
« Une fois qu'on a une vision claire du processus cible, qu'on a validé avec le métier, on peut aller tout droit sur les développements. On n'a plus besoin des allers-retours qu'on avait avant. »
Cinq façons de produire une note de cadrage qui ne sert à rien
Au-delà de la structure, la qualité d'une note de cadrage dépend de la qualité des informations qui la nourrissent. Voici les cinq erreurs les plus fréquentes qu'on observe.
La première : rédiger sans entretiens terrain. La note devient une projection de ce que les décideurs pensent que font leurs équipes, pas ce qu'elles font vraiment. Les règles implicites, les workarounds, les exceptions restent dans les têtes. Sur une PME de taille moyenne, comptez minimum 5 entretiens de 45 à 60 minutes avec des utilisateurs réels.
La deuxième : confondre fonctionnalités et processus. Une note de cadrage documente les processus qu'on cherche à transformer, pas les modules qu'on veut développer. La liste de fonctionnalités vient ensuite, comme conséquence logique des processus décrits.
La troisième : omettre les contraintes d'intégration. Chaque système existant (ERP, CRM, tableur partagé, plateforme EDI avec les clients) est une contrainte. Si elle n'est pas documentée en phase de cadrage, elle sera découverte en développement, au mauvais moment et au mauvais coût.
La quatrième : valider la note uniquement avec les sponsors, sans les utilisateurs finaux. Une note rédigée en chambre manque toujours quelque chose. Une session de review avec 2 à 3 utilisateurs clés est non-négociable.
La cinquième : traiter la note comme un document figé. Elle est un document vivant jusqu'à la fin de la phase de cadrage. Elle se complète et se corrige au fil des entretiens. C'est seulement après validation par toutes les parties prenantes qu'elle devient la référence commune.