Écrire un cahier des charges
Tu prépares un rapport BIBusiness Intelligence : transformer des données brutes en tableaux de bord lisibles par des gens qui ne font pas de SQL., mais la personne qui le demande ne sait pas encore dire ce qu'elle fera des résultats. Tu pourrais produire un écran correct qui ne l'aide à rien décider. Écris d'abord ce qu'elle doit pouvoir arbitrer et ce qui lui permettra d'accepter ton travail.
Un cahier des charges est le texte qui dit ce qu'on va faire, pour qui, avec quelles données, avec quels moyens, et ce qui comptera comme fini. Une première version cadre la demande avant l'analyse. Les contrôles de faisabilité sur les sources servent ensuite à la corriger avant validation. Sa forme et sa longueur dépendent du lecteur et du projet : une page peut convenir à un petit projet, sans être une règle générale.
Tu peux partir d'un indicateurUne mesure qu'on suit pour piloter une activité, comme le taux de livraisons en retard. Il se choisit à partir de la décision qu'il doit déclencher et du lecteur à qui il s'adresse. de la partie 1 du TP BI sur Olist, ou d'une question encore ouverte dans ta synthèse SQL. Tu précises la commande de travail ; tu n'as pas à refaire l'analyse ici. Pour retrouver une définition de mesure ou de population, utilise Définir un indicateur à partir d'un besoin.
Un document que son lecteur peut utiliser
Avant de lire la suite, écris qui lira ton cahier des charges et la décision que cette personne doit pouvoir prendre après lecture. Tu vérifieras ces deux points avec un lecteur à la fin de la fiche.
Pour l'exercice, un formateur ou une autre personne peut jouer le rôle du responsable qui formule la demande. Donne-lui ce rôle explicitement : il doit pouvoir dire si ce que tu proposes répond à son besoin, sans inventer les informations que ton texte laisse ouvertes.
Voici neuf rubriques à adapter avec cette personne. Leur ordre et leur longueur ne sont pas imposés : le lecteur doit pouvoir retrouver chaque information.
| Rubrique | Ce que le lecteur doit pouvoir retrouver |
|---|---|
| Le problème métier | Ce qu'on cherche à savoir. |
| La décision | Le choix que le résultat doit éclairer, et qui le fera. |
| Les données | Lesquelles il faut, où elles sont, qui les détient. |
| Hors périmètre | Ce que le projet ne couvre pas et pourquoi. |
| Les livrables | Ce qui sera remis, sous quelle forme, à qui. |
| Les étapes | Les résultats intermédiaires et leurs échéances à convenir. |
| Les moyens | Les personnes, accès, outils et coûts nécessaires. |
| Les risques | Ce qui peut faire échouer, comment le détecter et quoi faire. |
| Les critères de fin | Les contrôles qui permettront d'accepter le livrable. |
Une annexe peut porter le détail technique quand le lecteur du cahier des charges n'en a pas besoin pour valider le projet. Garde dans le document tout ce qui change le périmètre, les moyens ou les critères de fin.
De la demande à la problématique
Une problématique arrive rarement toute faite. Ce qu'on te donne est une phrase dite à l'oral, souvent en passant. Ton premier travail est de la réécrire.
Une problématique est une phrase qui contient deux choses : ce qu'on cherche à savoir, et quelle décision le résultat doit éclairer. Elle n'affirme pas à l'avance quelle décision sera prise. Des verbes comme choisir ou prioriser peuvent aider à la préciser, mais leur présence ne garantit rien. Demande au lecteur de nommer le choix concret que le résultat éclairera : ajouter « pour décider » à une phrase vague ne fournit pas ce choix.
Un exemple sur Olist. La demande, telle qu'un responsable la prononce :
« On a trop de mauvaises notes, il faut faire quelque chose. »
Propose d'abord une question mesurable et le choix qu'elle aiderait à faire. Garde cet essai, puis ouvre l'exemple.
Comparer une reformulation possible
« La part des notes de 1 ou 2 diffère-t-elle entre les commandes livrées en retard et celles livrées à l'heure, afin de décider s'il faut examiner en priorité les conditions de livraison ? »
Avant de lire la suite, prédis ce que cette comparaison permettrait d'affirmer si les deux parts étaient différentes.
Vérifier ce que la comparaison permettrait de conclure
Elle montrerait une associationDeux mesures qui varient ensemble, comme le retard de livraison et la note laissée par le client. Une association dit où regarder, elle ne dit pas laquelle des deux mesures agit sur l'autre., c'est-à-dire une différence observée entre deux groupes. Elle ne prouverait pas que le retard cause la note : le produit, le vendeur ou d'autres facteurs peuvent aussi différer. Le résultat sert donc à choisir une vérification suivante, pas à attribuer immédiatement la cause ni à décider seul d'une action sur les transporteurs.
Vérifier qu'une demande est exécutable
Voici trois phrases telles qu'un responsable les prononce :
1. « Il faudrait qu'on y voie plus clair sur les stocks. »
2. « Le service client passe son temps à répondre aux mêmes questions. »
3. « On dépense en publicité en ligne et je ne sais pas si ça sert. »
Ouvre le schémaLa description des tables d'une base : leurs noms, leurs colonnes, et le type de chaque colonne. Olist et cherche une table ou une colonne qui mesure chacun de ces trois sujets. Prédis lesquelles des demandes peuvent être traitées avec ces seules tables. Pour chaque demande, note la donnée manquante et une question à poser à la personne qui la détient, puis ouvre le contrôle.
Comparer la faisabilité avec les tables disponibles
Olist contient les commandes, leurs articles, leurs paiements, leurs livraisons et leurs avis. Il ne contient ni niveau de stock, ni motif des contacts au service client, ni dépenses et visites publicitaires. Aucune des demandes n'est donc traitable telle quelle. Cette étape évite de promettre une analyse impossible : mesure, population, source disponible et décision à éclairer doivent être définies, puis les accès et les moyens vérifiés.
Modifie ensuite la demande sur les avis Olist : précise la population de commandes comparée, la règle qui définit un retard et la mesure des notes faibles. Ajoute dans le livrable la limite « cette différence ne prouve pas une cause » et au moins une autre explication plausible à vérifier. Fais relire la phrase : le lecteur doit pouvoir désigner chaque élément sans l'inventer.
Le périmètre s'écrit, avec ce qu'il exclut
Dans une requête, un WHERE et un commentaire précisent quelles lignes tu
retires ou conserves. Ici, écris un paragraphe qui dit sur quelle population
porte le résultat et quels cas tu exclus.
La rubrique qui protège le projet est hors périmètre. Un projet dérive par ajout : une question de plus, un service de plus, une année de plus. Chaque ajout paraît petit sur le moment. Une ligne écrite avant, que le responsable a lue et acceptée, permet de dire non.
Sur Olist, un projet sur les retards de livraison pourrait écrire :
Hors périmètre : les commandes annulées ou non livrées, car la comparaison porte sur des livraisons réalisées ; le coût des transporteurs, car ces données ne décrivent pas leurs coûts internes.
Chaque ligne d'exclusion dit deux choses. Ce qu'on laisse de côté, et pourquoi on le peut. La dernière exclusion ci-dessus se justifie par une absence de donnée. La première se justifie par la question posée.
Ton tour : reprends ta problématique sur les avis Olist. Écris les exclusions nécessaires à cette comparaison. Pour chacune, note ce qui la justifie.
Prévoir un signal et une réponse aux risques
Nommer un risque avant le début du projet permet de prévoir un signal et une réponse. Trois familles reviennent dans les projets de données. Pour chacune, écris le risque, le moyen de le détecter et la réponse prévue.
La donnée absente. La colonne dont tu as besoin n'existe pas, ou existe et
n'est pas remplie. Sur Olist, les frais de port facturés ne décrivent pas le
coût interne des transporteurs. La parade : vérifier dans le schéma l'existence
de chaque colonne nécessaire, puis contrôler ses valeurs avant de finaliser le
cahier des charges. Pour une colonne existante, une requête COUNT(*) avec un
WHERE colonne IS NOT NULL compte les lignes où sa valeur n'est pas nulle.
Ce contrôle ne prouve pas à lui seul que les valeurs sont utilisables.
La donnée personnelle. Les données que tu vas manipuler concernent des clients, des salariés ou des fournisseurs. Le cahier des charges doit dire lesquelles, pourquoi, et où elles restent. Liste les colonnes nécessaires, les destinataires du résultat et les accès prévus. Avec le responsable, précise où les fichiers seront conservés et quand ils seront supprimés ; signale les choix encore à confirmer plutôt que d'inventer une durée.
Le délai. Le temps de l'entreprise n'est pas le tien. L'accès à une base peut prendre des semaines. Le responsable qui valide ton périmètre peut être absent. La parade : placer le premier livrable tôt, sur un extrait de données, pour que le projet montre quelque chose avant que le premier obstacle arrive.
Une ligne de risque s'écrit toujours de la même façon : ce qui peut arriver, comment on le verra, ce qu'on fera.
Les étapes, les ressources, le budget
Le référentiel demande une planification. Décris les étapes nécessaires, avec pour chacune un livrable et une échéance à convenir avec le responsable. Une date proposée reste à confirmer ; elle ne devient pas une consigne de formation.
Deux habitudes rendent cette liste utile.
La première : chaque étape se termine par quelque chose qu'on peut montrer. « Analyse exploratoire » ne désigne pas un résultat. « Un tableau des colonnes retenues, avec leur taux de remplissage » se montre. Sans livrable ni critère de fin, l'équipe ne peut pas vérifier que l'étape est achevée.
La seconde : le premier livrable arrive tôt, sur un extrait. Il sert à vérifier que tu as compris la demande avant d'engager toute la production.
Sur les ressources et le budget, écris ce dont tu as besoin en termes concrets : un accès en lecture à telle base, un rendez-vous avec telle personne, tel outil. Le budget recense les coûts prévisibles : licences ou infrastructure si elles sont nécessaires, ton temps et celui des personnes sollicitées. Une heure d'un responsable de service est une ressource à planifier comme le reste. Distingue les moyens confirmés des estimations et des accès encore à obtenir ; n'invente pas un budget pour remplir une case.
Préparer un premier livrable, puis utiliser le gabarit
Reprends la demande sur les avis que tu as précisée. Avant de copier le gabarit, écris seulement le premier livrable que tu remettrais et son critère de fin. Donne-les au lecteur : peut-il dire comment il vérifiera ce livrable ?
Si le critère de fin reste vague
Remplace « une analyse terminée » par un objet à relire, par exemple une fiche qui décrit la comparaison prévue. Le contrôle peut vérifier que le lecteur y retrouve la population, la règle de retard, la mesure des notes et la limite de l'interprétation. La fiche prépare le calcul ; elle ne donne pas son résultat. Ajoute qui fera ce contrôle et où retrouver la version remise.
Copie ce gabarit et remplis-le. Chaque crochet se remplace par une information précise que le lecteur peut valider ou corriger. Réutilise ton premier livrable et son contrôle. Signale les informations à obtenir et qui peut les confirmer.
# [Titre du projet]
**Demandé par** : [nom et fonction]
**Réalisé par** : [toi]
## Le problème métier
[Une phrase : ce que l'entreprise cherche à savoir.]
## La décision
[Le choix à éclairer et la personne qui le fera, sans annoncer le résultat.]
## Les données
- [Source 1 : où, qui la détient, ce qu'elle contient d'utile]
- [Source 2]
- Données personnelles : [finalité, colonnes, destinataires, accès,
conservation et suppression]
## Hors périmètre
- [Ce qu'on laisse de côté, et pourquoi on le peut]
- [...]
## Les livrables
- [Ce qui sera remis, sous quelle forme, à qui]
- [...]
## Les étapes
| Étape | Livrable | Échéance et statut de confirmation |
|---|---|---|
| [1] | [ce qu'on pourra montrer] | [proposée ou convenue avec qui] |
| [2] | | |
## Les risques
- [Ce qui peut arriver, comment on le verra, ce qu'on fera]
- [...]
## Les moyens et le budget
- Personnes et temps : [qui intervient, pour quoi, pendant combien de temps]
- Accès et outils : [ce qui existe déjà et ce qu'il faut obtenir]
- Coûts prévisibles : [licence, infrastructure ou « aucun coût supplémentaire
identifié », avec l'hypothèse qui le justifie]
## Les critères de fin
- [contrôle observable, personne qui le réalise et résultat attendu]
- [où retrouver la source, le calcul ou la version remise]Transférer à une autre demande
Choisis une autre question ouverte de ta synthèse SQL ou un indicateur de ton TP BI. Rédige son cahier des charges avec le gabarit, dans un format convenu avec le lecteur. Un sujet d'entreprise connu peut aussi servir, mais il n'est pas nécessaire pour faire l'exercice.
Pars des éléments déjà disponibles, puis distingue ce qui est confirmé de ce qu'il faut encore demander. Le livrable attendu est le cahier des charges, pas une réponse supplémentaire au TP. Une autre personne doit pouvoir y vérifier la population, les données disponibles, les limites, les moyens et les critères de fin.
Avant de le rendre, fais-le lire à quelqu'un qui ne connaît pas le projet. Demande-lui de nommer le choix à éclairer, puis de montrer dans ton texte le livrable qui y contribue et le contrôle qui permettra de l'accepter. S'il ne les retrouve pas, reprenez ensemble la rubrique concernée. Garde le premier essai, corrige le point manquant et fais rejouer ce contrôle.
Un responsable te dit : « Je voudrais comprendre pourquoi les clients ne reviennent pas. » Laquelle de ces phrases est une problématique au sens de cette fiche ?