DEMETER SANTE · Ressource pédagogique
Cahier des charges d’un projet IA : un modèle pour cadrer avant de développer
Par Dimitri Jorand · 11 octobre 2026
Cahier des charges d’un projet IA : le modèle de cadrage
Un cahier des charges de projet IA doit décrire un besoin vérifiable avant de promettre une technologie. Il précise qui utilisera le système, quelles données il pourra traiter, ce qu’il pourra faire et comment une décision de déploiement sera prise. Cette trame originale aide à préparer un atelier entre les métiers, la DSI, la sécurité, la protection des données et les responsables du projet.
Ressource de Dimitri Jorand, ajoutée le 11 octobre 2026. Elle complète le parcours en 90 jours, dont la durée reste un choix de méthode, et ne remplace pas les procédures d’achat ou les validations propres à votre structure. Le contenu est utilisable ici en HTML, sans formulaire ni dépôt de documents.
Commencer par la tâche et l’option sans IA
« Installer un assistant intelligent » ne décrit pas le travail à améliorer. Écrivez plutôt : « Aider les professionnels à retrouver le bon document administratif à jour. » Expliquez qui rencontre la difficulté, dans quelle situation et ce qui permettrait de juger la réponse utile. Comparez ensuite la recherche classique, une amélioration du classement et les approches IA.
La FAQ CNIL publiée le 18 juillet 2024 recommande de partir des usages et des risques, plutôt que du seul modèle. Les guides ANSSI de 2024 et 2025 éclairent la sécurité du système. La sécurité technique, la qualité métier et la conformité des traitements sont des sujets à articuler, pas trois noms pour le même contrôle.
Trame à compléter avec les responsables du projet
Chaque rubrique doit contenir une réponse, une preuve attendue ou un point ouvert avec son responsable. Un champ « à préciser » peut être honnête ; un champ vide qui disparaît du comité crée une fausse impression de préparation. Ne collez dans ce modèle aucune donnée de patient, aucun secret d’accès ni aucun dossier réel.
| Rubrique | Question à traiter | Élément à écrire ou vérifier |
|---|---|---|
| Besoin | Quel problème de travail voulons-nous résoudre ? | [Tâche, difficulté actuelle, résultat attendu, option sans IA] |
| Utilisateurs | Qui utilisera ou subira les effets du système ? | [Rôles, conditions d’accès, besoins d’accessibilité, accompagnement] |
| Périmètre | Quels usages sont autorisés ou exclus ? | [Tâches incluses, décisions interdites, limites et responsable d’arbitrage] |
| Données | Quelles sources sont nécessaires et légitimes ? | [Origine, sensibilité, droits d’usage, mise à jour, conservation et destinataires] |
| Interfaces | Quels systèmes échangent des informations ? | [Entrées, sorties, services tiers, flux, dépendances et frontières de confiance] |
| Permissions | Que peut consulter, modifier ou déclencher chaque rôle ? | [Matrice de droits, autorisations serveur, validation humaine et traces] |
| Qualité | Sur quels cas vérifierons-nous l’utilité et les limites ? | [Jeu de tests, critères d’acceptation, erreurs critiques, réponse d’incertitude] |
| Sécurité et conformité | Quels risques et cadres faut-il examiner ? | [Analyse, mesures, interlocuteurs compétents, décisions et points ouverts] |
| Coûts | Quels postes existent pendant et après le pilote ? | [Intégration, consommation, licences, exploitation, formation, plafond et alerte] |
| Réversibilité | Comment exporter, arrêter et poursuivre le travail sans le système ? | [Formats, droits, dépendances, suppression, délai et test de sortie] |
| Exploitation | Qui maintient les documents, les accès et le service ? | [Responsabilités, mises à jour, incidents, supervision et requalification] |
| Déploiement | Qui peut décider de continuer, ajuster ou arrêter ? | [Comité, critères, limites du périmètre autorisé et décision datée] |
Exemple entièrement fictif : retrouver une procédure administrative
Une structure inventée souhaite aider un groupe de professionnels à retrouver des procédures administratives publiables : réservation d’une salle, demande de matériel pédagogique ou contact d’un service support. Le projet ne traite ni dossier de patient ni décision de recrutement, d’accès aux droits ou de soins. Les documents de test sont des créations fictives et ne reproduisent aucun document réel.
Le besoin n’est pas « répondre à toutes les questions de l’établissement ». Il est de retrouver une référence autorisée, d’en montrer la version et d’indiquer la démarche prévue dans le document. Le pilote reste en lecture seule. Il ne réserve pas la salle, n’envoie pas de courriel et ne modifie pas un formulaire. Si le document manque ou si deux versions se contredisent, il doit l’annoncer et proposer le relais prévu.
| Souhait trop général | Condition de test proposée | Preuve attendue |
|---|---|---|
| « Donner la bonne réponse » | Pour chaque cas du jeu d’essai, retrouver le document autorisé et sa version, ou annoncer l’absence de référence. | Résultat et référence comparés par un responsable métier ; jeu d’essai versionné. |
| « Respecter les accès » | Un rôle non autorisé ne reçoit ni le document interdit, ni un extrait, ni une information de son existence. | Tests négatifs sur les rôles, contrôles serveur et revue des traces. |
| « Être prudent » | Une consigne hostile placée dans un document ne modifie ni les droits ni le périmètre de réponse. | Cas de test préparés, résultats examinés et corrections vérifiées. |
| « Rester abordable » | Le projet a un plafond de dépenses, un responsable du suivi et une solution de secours annoncée. | Budget par poste, alerte testée et procédure d’arrêt vérifiée. |
| « Pouvoir changer de fournisseur » | Exporter le corpus autorisé, les réglages et les traces nécessaires dans les formats convenus. | Exercice de sortie réellement exécuté, pas seulement une clause commerciale. |
Aucun taux de réussite ou gain de temps n’est annoncé dans cet exemple. Les critères précis et les seuils éventuels sont à décider avant le test, avec les métiers et les responsables compétents. Ce périmètre fictif n’établit pas que tous les assistants administratifs ont la même qualification réglementaire.
Permissions et données : rendre les limites explicites
Le cahier des charges doit identifier ce qui entre dans le système et ce qui en sort, y compris les journaux, les services de modèles et les sauvegardes. « Hébergé en France » ne répond pas, à lui seul, aux questions d’accès, de sous-traitance ou de conservation. Une offre, une certification ou une qualification d’hébergement doivent être vérifiées pour leur périmètre réel ; elles ne rendent pas automatiquement l’ensemble du projet conforme ou HDS.
Documentez les validations requises avec les responsables de la sécurité, de la protection des données et, selon le cas, de l’achat et du droit. Ne déduisez pas d’un essai technique une autorisation générale d’utiliser le système. Les données personnelles, les finalités médicales et les usages sensibles demandent une analyse propre, qui ne peut pas être faite en cochant ce seul tableau.
Choix technique : justifier plutôt que collectionner les outils
Le guide agent IA, chatbot ou automatisation aide à préciser le niveau d’action attendu. Si le projet consiste à retrouver des documents, le comparatif RAG et fine-tuning peut éclairer le choix. Aucun choix n’écarte le besoin de vérifier les droits et l’actualisation des sources.
Pour définir le jeu d’essai, notre grille d’évaluation d’un assistant IA fournit un point de départ. La recette doit comporter des erreurs possibles, des absences de réponse et des refus attendus, pas seulement les exemples sur lesquels une démonstration commerciale fonctionne.
La décision de déploiement reste un livrable
Au comité, revenez aux critères écrits avant le développement. Listez les résultats observés, les risques restants, les coûts et les conditions d’exploitation. « Continuer » autorise un périmètre précis, pas toutes les évolutions futures. « Ajuster » indique ce qui doit être corrigé et recontrôlé. « Arrêter » organise le retour au fonctionnement prévu et la conservation des enseignements utiles.
DEMETER SANTE peut accompagner le diagnostic, le cadrage, la formation et le développement de solutions sur mesure, avec son partenaire stratégique JustAI selon le projet. Découvrez nos services IA ou préparez un échange sur votre besoin. Aucun résultat, calendrier de conformité ou qualification d’hébergement n’est garanti par cette trame.
Questions pratiques
Que doit contenir un cahier des charges de projet IA ?
Il précise le besoin métier, les utilisateurs, le périmètre, les données, les interfaces et permissions, les critères de qualité, la sécurité, les coûts, la réversibilité, l’exploitation et la décision de déploiement. Les points inconnus restent identifiés avec une personne chargée de les résoudre, plutôt que complétés par supposition.
Faut-il choisir le modèle d’IA avant de rédiger le besoin ?
Non. Décrivez d’abord la tâche et le résultat attendu, puis comparez les approches, y compris une solution sans IA. Le choix technique doit être justifié par le besoin, les risques, les contraintes et les tests. Un nom de modèle ne remplace pas un critère d’acceptation.
Ce document est-il une trame de marché public prête à signer ?
Non. C’est un support pédagogique de cadrage et de discussion, pas un dossier de consultation, une clause contractuelle ou un avis juridique. Les achats, la protection des données, la sécurité et le cadre réglementaire doivent être examinés avec les responsables compétents.
Sources et limites du modèle
Sources primaires consultées le 11 octobre 2026 : FAQ CNIL du 18 juillet 2024, guide ANSSI du 29 avril 2024 et approche ANSSI par les risques cyber du 7 février 2025. Modèle pédagogique original de Dimitri Jorand, sans reproduction des guides. Ce n’est ni une trame de marché public juridiquement prête à signer, ni une étude de conformité, ni une certification de sécurité.