# Cahier des charges — Application métier

Modèle SEYA LABS — version du 5 octobre 2026
https://seyalabs.com/insights/cahier-des-charges-application-metier
Contact : contact@seyalabs.com

Ce document sert à préparer le cadrage. Il ne remplace pas le contrat de réalisation.
Copiez-le, complétez-le et supprimez les rubriques qui ne concernent pas votre projet.
Évitez d’y inclure des données personnelles ou confidentielles inutiles au cadrage.

## 1. Le projet et ses responsables

- Nom du projet :
- Entreprise :
- Responsable métier et décideur :
- Interlocuteur technique :
- Utilisateurs à consulter :
- Version du document et date :

## 2. Le problème à résoudre

- Fonctionnement actuel :
- Friction principale et conséquences :
- Premier changement attendu :
- Observations de départ (volumes, délais, erreurs), source et période :
- Ce que le projet ne cherche pas à changer :

## 3. Les utilisateurs et leurs droits

Pour chaque rôle, compléter :

- Nom et personnes concernées :
- Informations consultables et périmètre (équipe, site, dossiers…) :
- Actions autorisées (créer, modifier, valider, exporter, supprimer…) :
- Actions interdites :
- Qui crée et retire les accès :
- Qui valide les règles de ce rôle :

## 4. Un parcours complet

Dupliquer cette fiche pour chaque parcours prioritaire.

- Nom du parcours :
- Déclencheur :
- Acteurs :
- Données d’entrée obligatoires et leur source :
- Étapes et règles de décision :
- Résultat attendu :
- Cas de données manquantes :
- Cas de doublon :
- Cas de correction après validation :
- Cas d’annulation ou d’interruption :
- Personne qui tranche les exceptions :

## 5. Les données et leur reprise

Pour chaque source :

- Logiciel, fichier, base ou document :
- Propriétaire et possibilités d’export :
- Volumes et formats connus :
- Identifiants et relations à conserver :
- Source de référence en cas de conflit :
- Doublons et anomalies connus :
- Données actives et historique à reprendre :
- Archives exclues et moyen d’y accéder :
- Échantillon disponible pour tester la reprise :
- Responsable de validation des données migrées :

Pour chaque transformation : champ source → champ cible, règle, cas manquant, contrôle, responsable.

## 6. Les intégrations

Pour chaque logiciel à connecter :

- Nom du logiciel et interlocuteur :
- Documentation API et environnement de test disponibles :
- Action ou donnée échangée et sens du flux :
- Déclencheur et fréquence :
- Identifiants de correspondance :
- Permissions nécessaires :
- Quotas et autres limites connus :
- Comportement attendu sur erreur, interruption et événement répété :
- Qui suit les erreurs et autorise une reprise :

## 7. La première version et les arbitrages

- Parcours indispensables à la première livraison :
- Fonctions utiles après observation :
- Fonctions exclues :
- Tâches restant manuelles et leur responsable :
- Date souhaitée et raison de cette contrainte :
- Disponibilité de l’équipe pour les ateliers et la recette :
- Enveloppe budgétaire connue, ou point à préciser :

## 8. Les critères de recette

Dupliquer pour chaque scénario à vérifier :

- Identifiant et nom du test :
- Rôle et données de départ :
- Action réalisée :
- Résultat attendu observable :
- Exception ou erreur à vérifier :
- Preuve du résultat (écran, état, trace, rapprochement…) :
- Personne qui valide :
- Statut, anomalie et décision :

Prévoir au minimum : un parcours normal, des droits refusés, une donnée invalide,
une interruption si pertinente et des contrôles de migration si incluse.

## 9. Le lancement et l’exploitation

- Appareils, réseau et éventuel besoin hors connexion :
- Volumes et périodes d’usage :
- Contraintes de disponibilité à définir :
- Hébergement et comptes sous responsabilité de :
- Données traitées et exigences à examiner avec les interlocuteurs concernés :
- Sauvegarde, restauration et contrôles prévus :
- Alertes, support et responsable de reprise :
- Moment où l’ancien outil cesse d’être la référence :
- Conditions de report ou de retour sur incident :
- Formation et accompagnement :
- Documentation, accès et livrables attendus :
- Maintenance, évolutions et transfert à clarifier dans le contrat :

## 10. Les inconnues et dépendances

Pour chaque point : question, conséquence sur le projet, responsable, prochaine action et échéance.

- Règle métier non décidée :
- Accès ou API non vérifié :
- Qualité des données non examinée :
- Arbitrage de périmètre :
- Autre dépendance :

## 11. La prochaine étape

- Parcours à examiner en premier :
- Documents et exemples à réunir :
- Participants au cadrage :
- Décisions attendues :

Vous pouvez partager ce document, même incomplet, pour une première discussion :
contact@seyalabs.com — https://seyalabs.com/contact