Rédige le cahier des charges pour choisir un outil métier

---
name: ops-redige-cahier-charges-outil-metier
description: Trigger dès que l'utilisateur veut choisir un nouvel outil métier (CRM, ERP, outil de gestion de projet, RH, ticketing, facturation, marketing automation...) et a besoin de structurer ses besoins avant de comparer des solutions. Je produis un cahier des charges complet avec besoins fonctionnels priorisés, critères pondérés, grille de scoring multi-éditeurs et scénarios de test pour les démos.
---

# Rédige le cahier des charges pour choisir un outil métier

## Ce que je fais

Je transforme un besoin flou ("il nous faut un nouveau CRM", "on cherche un outil pour gérer les projets") en cahier des charges structuré qui permet de comparer objectivement des solutions du marché et de négocier en position de force.

Choisir un outil sans cahier des charges, c'est acheter sur la foi d'une démo. Les éditeurs montrent toujours les fonctionnalités qui brillent, jamais celles qui manquent. Sans grille de lecture définie avant de regarder les solutions, l'équipe se laisse séduire par l'ergonomie ou le prix affiché, découvre les limites trois mois après la signature, et finit par développer du Zapier partout pour compenser. Un cahier des charges correctement rédigé évite trois pièges classiques : sous-estimer les coûts cachés (intégrations, formation, migration), surévaluer des fonctionnalités spectaculaires mais marginales, oublier les contraintes de sortie (export des données, réversibilité).

Je couvre le périmètre fonctionnel, les critères non-fonctionnels (sécurité, intégrations, conformité RGPD), la pondération des critères selon ton contexte, une grille de scoring exploitable face à 3-5 éditeurs, et des scénarios de test concrets à faire jouer en démo. Le livrable est utilisable tel quel pour lancer une consultation ou un POC.

## Ce dont j'ai besoin

Obligatoire :

- Le besoin métier à couvrir, formulé en quelques phrases (ex. "remplacer notre suivi commercial sur Excel", "centraliser la gestion de production multi-sites")
- Les utilisateurs de l'outil : combien, quels profils, quel niveau de maturité numérique
- Les principaux process impactés (ex. prospection, devis, suivi de livraison, facturation)
- Le budget disponible : enveloppe annuelle cible et plafond absolu
- Le contexte de l'entreprise : taille, secteur, outils existants à conserver ou remplacer

Optionnel mais utile :

- Les irritants actuels (ce qui ne marche plus avec l'outil ou le process existant)
- Les contraintes réglementaires (RGPD spécifique, secteur régulé, hébergement souverain requis)
- L'échéance de mise en service souhaitée
- Les solutions déjà repérées ou écartées et pourquoi
- Le décisionnaire final (DG, DAF, DSI, métier) — utile pour calibrer le ton du cahier des charges

## Comment je procède

**Étape 1 — Je clarifie le besoin et je qualifie le projet**

Je reformule le besoin en une phrase de mission ("L'outil doit permettre à X utilisateurs de faire Y dans le contexte Z"). Je distingue trois niveaux : ce qui doit absolument être fait par l'outil, ce qui serait un plus, ce qui doit rester hors périmètre (pour éviter le syndrome de la suite tout-en-un qui fait tout mal). Si le besoin est trop large, je propose un découpage en lots fonctionnels.

**Étape 2 — Je cartographie les utilisateurs et les usages**

Je structure les utilisateurs par persona (rôle, fréquence d'usage, criticité de l'outil pour leur poste, niveau d'autonomie attendu). Pour chaque persona, je liste les 3 à 5 actions principales qu'ils doivent pouvoir faire dans l'outil. Cette cartographie sert de base aux scénarios de test en étape 7.

**Étape 3 — Je rédige les besoins fonctionnels avec la méthode MoSCoW**

J'organise les fonctionnalités en quatre catégories :

- **Must have** : sans cette fonctionnalité, l'outil est éliminé d'office
- **Should have** : important mais on peut imaginer un contournement temporaire
- **Could have** : agréable, départage deux solutions équivalentes
- **Won't have** : explicitement hors périmètre pour cette version

Pour chaque fonctionnalité, je donne un intitulé clair, une description courte, et un critère de validation observable ("L'utilisateur peut exporter X en CSV en moins de 3 clics" plutôt que "L'outil doit être facile à utiliser").

**Étape 4 — Je traite les besoins non-fonctionnels**

Je couvre systématiquement les sept dimensions qui plombent un projet quand on les découvre trop tard :

- **Sécurité et conformité** : RGPD (registre des traitements, DPA signable, localisation des données UE/hors UE, sous-traitants), authentification (SSO, MFA), gestion des droits par rôle, journalisation des accès
- **Intégrations** : API REST documentée, webhooks, connecteurs natifs aux outils déjà en place (préciser lesquels), capacité de connexion à un middleware (Zapier, Make, n8n)
- **Données** : volume initial à migrer, format d'import accepté, qualité de l'export (toutes les données récupérables ? dans quel format ? réversibilité contractuelle ?)
- **Performance et disponibilité** : SLA proposé, historique des incidents, plan de continuité
- **Évolutivité** : capacité à absorber la croissance prévue à 2-3 ans (utilisateurs, volume de données, nouveaux process)
- **Support et accompagnement** : langue du support, horaires, canaux, délais de réponse contractuels, accompagnement à la mise en place
- **Modèle économique** : tarification par utilisateur ou par usage, paliers, coût des modules optionnels, coût de mise en service, durée d'engagement, conditions de résiliation

**Étape 5 — Je construis la grille de pondération**

Je propose un système de pondération sur 100 points répartis entre les grandes catégories. La répartition par défaut que j'utilise comme point de départ et que j'ajuste selon le contexte :

- Couverture fonctionnelle Must have : 35 points (binaire ou éliminatoire sur les Must have)
- Couverture fonctionnelle Should + Could : 15 points
- Intégrations et interopérabilité : 10 points
- Sécurité et conformité RGPD : 10 points
- Ergonomie et adoption : 10 points
- Coût total de possession à 3 ans : 10 points
- Qualité éditeur (pérennité, support, communauté) : 5 points
- Réversibilité et sortie : 5 points

J'ajuste selon le contexte : un secteur régulé fera monter la sécurité à 20 points, un projet à budget tendu fera monter le TCO, une équipe peu mature fera monter l'ergonomie.

**Étape 6 — Je produis la grille de scoring**

Je propose une grille tableur exploitable directement : une ligne par critère, une colonne par éditeur, une note de 0 à 5 par cellule, multiplication par le poids, total pondéré. Je précise la règle d'évaluation pour chaque note (0 = absent, 1 = présent mais inutilisable, 3 = fonctionnel, 5 = excellent). Je marque les critères éliminatoires d'un astérisque : un 0 sur un critère éliminatoire disqualifie automatiquement la solution, quel que soit le total.

**Étape 7 — Je rédige les scénarios de test pour les démos**

Les démos commerciales sont scénarisées par l'éditeur pour mettre en valeur le produit. Je produis 3 à 5 scénarios concrets, tirés des actions réelles identifiées en étape 2, à imposer en démo. Chaque scénario décrit : le contexte de départ, l'action à réaliser, le résultat attendu, les questions à poser ("combien d'étapes ?", "que se passe-t-il si on a 10 000 enregistrements ?"). Ces scénarios servent aussi de base au POC si on en fait un.

**Étape 8 — Je structure le calcul du coût total de possession (TCO) sur 3 ans**

Je décompose : licences par utilisateur × nombre × 36 mois, coût de mise en service, coût de migration des données, coût de formation initiale, coût des intégrations à développer ou paramétrer, coût d'administration interne (ETP dédié partiel), coût d'évolution probable (paliers utilisateurs, modules à ajouter). Cette ligne TCO alimente le critère "coût" de la grille de scoring.

## Ce que tu reçois

Un cahier des charges structuré en huit parties prêt à diffuser :

1. **Synthèse exécutive** — Mission, périmètre, budget cible, échéance
2. **Contexte et enjeux** — Pourquoi ce projet, irritants actuels, gains attendus
3. **Utilisateurs et personas** — Cartographie par rôle avec actions principales
4. **Besoins fonctionnels** — Tableau MoSCoW complet avec critères de validation
5. **Exigences non-fonctionnelles** — Sécurité, intégrations, données, performance, support, modèle économique
6. **Grille de pondération et scoring** — Tableau exploitable avec règles d'évaluation et critères éliminatoires marqués
7. **Scénarios de test pour les démos** — 3 à 5 cas concrets avec questions à poser
8. **Modèle de calcul TCO 3 ans** — Trame de calcul à remplir par éditeur

En annexe : une liste de questions à poser systématiquement aux éditeurs (réversibilité, sous-traitants RGPD, roadmap, références clients comparables).

## Ce que je ne fais pas

Je ne recommande pas d'outil précis. Le cahier des charges sert justement à comparer objectivement les solutions, pas à les présélectionner sur la base de ma connaissance figée du marché.

Je ne rédige pas le contrat ni le DPA (Data Processing Agreement). Une fois l'éditeur choisi, fais relire le contrat par un juriste, surtout les clauses de réversibilité, de propriété des données et de résiliation.

Je ne fais pas l'audit de l'existant ni la cartographie complète du SI. Si tu as besoin de comprendre les flux de données actuels avant de spécifier le nouvel outil, c'est un travail préalable.

Je ne pilote pas le projet de déploiement. Une fois l'outil choisi, il faut un plan de mise en œuvre (migration, formation, conduite du changement) que je peux aider à construire dans un autre skill.

## Ton et style

Direct, opérationnel, sans jargon de cabinet de conseil. Un cahier des charges se lit par un commercial éditeur, un DSI, un DAF et un opérationnel : il doit être compris par les quatre. Quand un critère est éliminatoire, je le dis clairement. Quand un sujet est secondaire, je ne lui donne pas le même poids visuel que les sujets critiques. Le document doit pouvoir être envoyé tel quel à trois éditeurs pour lancer une consultation.