Initial IADécouvrir l’offre ↗
← Toutes les ressources

Cadrage de projet · Guide pratique

Cahier des charges d'un projet IA : modèle et exemple rempli

Préparer un dossier de consultation et comparer les réponses sur les mêmes exigences.

Chaîne de preuve d'une exigence : R03 identité ambiguë, test T02 avec deux clients, aucun identifiant sélectionné, résultat observé à renseigner et décision du responsable.

Un cahier des charges IA utile permet de répondre à trois questions : quel travail le système prend-il en charge, où doit-il s'arrêter et sur quelles preuves accepterez-vous sa livraison ? Écrivez ces réponses avant de comparer les outils. « Préparer une fiche depuis un email, puis attendre l'accord de l'assistante » définit déjà un projet plus précis que « automatiser notre administratif ».

Préparer un dossier de consultation et comparer les réponses sur les mêmes exigences.

Lire le dossier illustré de six pages, puis remplir le modèle Word de trois pages.

Télécharger le kit de cet article

Le dossier PDF suit un cas de la demande au choix du pilote. Le modèle Word à remplir rassemble votre besoin, vos critères et la réponse attendue du prestataire. Commencez par ces deux documents ; le kit contient les annexes de travail. Aucun formulaire n'est nécessaire pour les télécharger.

Vérifier que le besoin demande de l'IA

Avant de cadrer une IA, regardez ce qui rend la tâche difficile. Si le formulaire fournit déjà un identifiant client, un site et une date dans des champs fiables, une connexion entre outils peut suffire. Ajouter un modèle ne dispense pas de vérifier les droits, les doublons et les erreurs de transfert.

L'IA devient une piste à essayer lorsque l'entrée demande une interprétation : des emails formulés différemment, plusieurs informations mêlées, une description à extraire. Mais si le référentiel contient deux clients indiscernables, le modèle ne dispose pas soudain d'une preuve permettant de choisir.

Situation observée Première action raisonnable
Champs structurés et règle déterministe Étudier une connexion ou une règle existante
Texte variable, résultat attendu vérifiable Tester une extraction assistée sur des exemples
Sources contradictoires, droits ou décisionnaire inconnus Résoudre ce point de cadrage avant d'autoriser l'action

Dans la consultation, demandez donc aussi quelle partie peut fonctionner sans IA. Vous pourrez comparer le coût et la facilité de reprise sur le même service rendu, plutôt que sur le nombre de fonctions annoncées.

Écrire le besoin sur une page

Prenons une entreprise de maintenance fictive. Elle veut préparer des fiches d'intervention depuis une boîte dédiée. Le pilote doit créer une proposition que l'assistante peut relire ; il ne doit ni planifier un technicien ni promettre un prix.

Décision de cadrage Réponse retenue pour l'exercice
Entrée Email M-001 et référentiel clients autorisé, version R-01
Résultat Proposition P-001 avec client, site, problème, date demandée et sources
Autorisation Création dans le registre de test uniquement après accord sur la version exacte
Exclusions Aucun rendez-vous, achat, engagement tarifaire ou email client
Inconnue Champ vide et motif de revue ; aucun choix forcé
Indisponibilité Mise en attente ; responsable d'exploitation à désigner pour la reprise
Décision suivante Valider le périmètre et l'accès au registre avant devis de réalisation

Pour votre entreprise, joignez un exemple réel autorisé ou anonymisé et sa sortie attendue. Notez qui confirme chaque règle. Un exemple pédagogique ne remplace pas la vérification de vos droits de partage.

Le modèle guidé en texte reste disponible si vous préférez travailler sans Word. Marquez chaque réponse « confirmé », « hypothèse » ou « ouvert ». Une question ouverte doit avoir un responsable ; ne la faites pas disparaître dans une formulation vague.

Besoin, données et autorisations conduisent à une proposition validée, puis à une recette. Chaque exigence doit avoir un test et un responsable.
Besoin, données et autorisations conduisent à une proposition validée, puis à une recette. Chaque exigence doit avoir un test et un responsable.

Suivre une demande jusqu'à sa validation

Voici M-001 : « Pour le site Rouen-02, la porte reste bloquée. Pouvez-vous intervenir le 30 septembre 2026 ? » Le référentiel fictif rattache cet expéditeur à C-017 et autorise Rouen-02. Ces deux informations viennent du référentiel, pas d'une déduction du modèle.

Champ proposé Valeur attendue Justification
Client C-017 Correspondance unique dans R-01
Site Rouen-02 Message et site autorisé dans R-01
Problème « la porte reste bloquée » Citation de M-001
Date demandée 2026-09-30 Demande explicite du client
Date confirmée et prix Non renseignés Aucun engagement disponible

L'assistante approuve P-001 v1. Si quelqu'un remplace ensuite la date pour produire v2, l'accord sur v1 ne doit pas autoriser v2. Si l'assistante est absente, la demande attend : le silence n'est pas un accord.

Cette séquence rend une exigence testable. Elle permet de demander une preuve précise au prestataire : version proposée, accord reçu et état réellement enregistré. Une phrase « intervention créée » dans une réponse ne suffit pas à constater la création.

L'exemple rempli conserve aussi les questions encore ouvertes : outil de production, volumes, hébergement et personne de remplacement. Il permet une discussion de cadrage ; il ne justifie pas encore un forfait de réalisation sans hypothèses.

Remplacer les promesses par des essais observables

« Une IA fiable à 95 % » ne dit pas si une écriture non autorisée fait partie des 5 % restants. Définissez d'abord les échecs qui interdisent l'utilisation prévue. Une erreur de mise en forme et une fiche créée chez le mauvais client n'ont pas la même conséquence.

La matrice de recette relie sept exigences à des tests. Les cas détaillés précisent entrées, état initial, attendu et preuve à recueillir : demande complète, identité ambiguë, date absente, accord absent ou périmé, reprise, accès interdit et export.

Chaîne de preuve d'une exigence : R03 identité ambiguë, test T02 avec deux clients, aucun identifiant sélectionné, résultat observé à renseigner et décision du responsable.
Chaîne de preuve d'une exigence : R03 identité ambiguë, test T02 avec deux clients, aucun identifiant sélectionné, résultat observé à renseigner et décision du responsable.

Pour la reprise, faites créer une fiche puis perdez volontairement la réponse dans l'environnement de test. Rejouer aveuglément la création peut produire un doublon. Demandez comment le système retrouve l'opération et ce qui protège contre deux reprises simultanées. Une recherche suivie d'une création ne suffit pas, à elle seule, à démontrer cette protection.

Pour les droits, une réponse qui ne révèle pas le contenu interdit n'est qu'un indice. Il faut aussi contrôler les sources récupérées et ce qui est transmis au modèle. Si les traces nécessaires manquent, le statut reste « non vérifié ».

Voici un compte rendu inventé pour apprendre à décider, distinct de tout essai réel : au test T04, v1 est approuvée, la date change dans v2, puis v2 est créée avec l'ancien accord. La décision est « corriger puis retester », même si les six autres tests réussissent. Après correction, rejouez T04 et les tests liés aux écritures et à la reprise. Conservez l'échec initial dans l'historique.

Comparer deux offres sans comparer deux projets différents

Envoyez la même version du besoin et les mêmes annexes. Demandez une réponse « inclus », « exclu » ou « à préciser », accompagnée d'une preuve ou d'un livrable attendu. La grille de comparaison prévoit une place pour la référence exacte de chaque réponse.

Dans deux offres fictives, A prévoit la validation avant création ; B crée automatiquement et propose une revue le lendemain. B ne répond pas à notre exigence R04. Son prix ne compense pas cet écart : demandez une variante conforme avant de classer les offres. La promesse de A reste, elle aussi, à éprouver.

Le PDF pousse la comparaison jusqu'au chiffrage : A annonce 4 200 € de mise en place puis 180 €/mois ; B, 2 900 € puis 320 €/mois. Sur douze mois de service, les sous-totaux fournisseur sont respectivement 6 360 € et 6 740 € HT. Ces montants sont inventés, sans valeur de tarif. Ils excluent le temps interne et ne constituent pas un coût complet. Leur intérêt : montrer pourquoi le prix de départ ne suffit pas.

Avant de retenir une offre, faites préciser consommation incluse, dépassements, maintenance, formation, export et interventions hors forfait. Un poste inconnu reste inconnu. Faites préciser aussi le travail attendu de votre équipe et ce qui déplace une échéance : accès manquant, données à corriger, validation indisponible.

Mesurer le travail restant avant de parler d'économie

Le cas de calcul est une simulation indépendante, pas le volume mesuré de l'entreprise fictive : 1 000 dossiers à six minutes représentent 100 heures mensuelles. Avec deux minutes de revue par dossier, cinq heures de correction et cinq heures d'exploitation, il reste environ 43,3 heures ; la capacité théoriquement libérée vaut 56,7 heures.

Bilan de temps fictif : cent heures initiales contre 33,3 heures de validation, cinq heures de correction et cinq heures d'exploitation ; gain théorique de 56,7 heures.
Bilan de temps fictif : cent heures initiales contre 33,3 heures de validation, cinq heures de correction et cinq heures d'exploitation ; gain théorique de 56,7 heures.

La conclusion change si la relecture dure quatre minutes : le travail restant passe à 76,7 heures, soit seulement 23,3 heures libérées. Pour ces hypothèses, le gain de temps disparaît à 5,4 minutes de revue par dossier. Cette limite est plus utile qu'une seule estimation favorable : elle indique quelle durée mesurer pendant le pilote.

La feuille d'hypothèses et le calculateur servent à remplacer ces valeurs. Comparez des tâches de même périmètre, gardez les corrections et les refus, et vérifiez la qualité en même temps que le temps. Ajoutez séparément conception, formation et coûts du service pour étudier la rentabilité. Une heure disponible ne devient une économie de trésorerie que si une dépense baisse effectivement.

Décider de poursuivre corriger ou arrêter

Découpez le projet en décisions. Le cadrage fixe entrées, sorties et droits. Le prototype permet d'examiner le parcours. La recette vérifie des cas convenus. Le pilote confronte le fonctionnement au travail supervisé ; la mise en service ajoute exploitation et transmission.

Jalons de projet : cadrage, prototype, recette, pilote et mise en service ; chaque étape produit une preuve avant la suivante.
Jalons de projet : cadrage, prototype, recette, pilote et mise en service ; chaque étape produit une preuve avant la suivante.

Gardez des dossiers à l'écart des réglages. Si tous les cas ont servi à corriger la solution, constituez un nouveau lot avant d'apprécier son comportement sur des entrées nouvelles. Les sept cas du kit apprennent la méthode ; ils ne mesurent pas une fiabilité générale.

Le registre de décision doit répondre à quatre questions : quels critères bloquants passent, quelles observations restent inconnues, qui accepte les réserves et qui reprend le service ? Le tableau des jalons aide à nommer les décideurs.

Poursuivez le pilote si les preuves requises sont disponibles et acceptées. Corrigez puis retestez un défaut réparable. Réduisez ou arrêtez le périmètre si une contrainte obligatoire ne peut pas être respectée. Demandez enfin au relais de retrouver une demande, d'expliquer son état et de préparer une reprise sans l'auteur du système à côté de lui.

Préparer le message au prestataire

Nous souhaitons préparer une fiche depuis une demande reçue par email.
Vous trouverez le besoin versionné, un exemple et les cas de recette.
Merci de distinguer ce qui est inclus, exclu ou encore à préciser.
Décrivez la solution minimale, y compris ce qui peut fonctionner sans IA.
Séparez cadrage, installation, coûts récurrents et travail de notre équipe.
Pour chaque exigence bloquante, indiquez le test et la preuve proposés.
Listez les accès nécessaires, les hypothèses et les conditions de reprise.
Aucune écriture ni diffusion n'est autorisée avant la validation convenue.

Vous pouvez envoyer une demande de cadrage même si l'outil cible ou le volume reste à préciser. Dites-le dans le message : vous achetez alors la résolution de ces inconnues avant de demander un engagement de réalisation. Le parcours de préparation précise les pièces à joindre.

Les références soutiennent la méthode, pas des résultats clients : France Num pour l'organisation du travail ; les recommandations britanniques de 2020 pour le besoin et les données avant l'achat, sans transposer leur cadre juridique ; Anthropic pour distinguer résultat annoncé et état réellement obtenu. Les documents de ce guide sont originaux.

À vous de décider : 56,7 heures représentent-elles une économie ?

Cas fictif : le calcul mensuel passe de 100 heures à 43,3 heures de travail restant. Aucun coût de conception ou de formation n'a été ajouté. Peut-on annoncer un retour sur investissement démontré ?

  • A. Oui : 56,7 heures libérées prouvent une économie de trésorerie.
  • B. Non : il s'agit d'une capacité théorique, à mesurer et à rapprocher des coûts complets.
  • C. Oui, si l'on multiplie ces heures par n'importe quel taux horaire.
Voir la correction commentée

B. L'exercice évalue une différence de temps sous des hypothèses choisies. Il reste à mesurer la qualité, les corrections et la possibilité de réaffecter cette capacité. Ajoutez conception, formation, logiciels et exploitation selon le périmètre retenu, sans compter deux fois un poste. Le calculateur ne constitue ni une mesure terrain ni une promesse de rentabilité.

À adapter : quel travail concret absorbera le temps libéré, et quelles données permettront de le vérifier ?

Essayer vos hypothèses dans le calculateur. Les calculs restent sur votre appareil ; aucune donnée n’est envoyée.

L'atelier de cadrage Initial IA peut transformer ces pièces en périmètre de pilote. Venez avec un exemple représentatif et un résultat attendu ; les zones encore inconnues feront partie du travail de cadrage.

Rédaction Initial IA, 26 septembre 2026. Enrichissement le 27 septembre 2026. Source, modèle et calculs relus le 5 octobre 2026. Modèle et entreprise fictifs ; contrôle de couverture de la recette, sans validation d'un projet client.

À vous de l’essayer.

Retrouvez les documents fictifs, les modèles vierges et les corrigés dans le kit pratique.

Télécharger le kit de cet article