9 min de lecture - Modèle de SOW pour projets IA : fondateurs et achats

La plupart des projets IA n'échouent pas par manque de compétences techniques.

Ils échouent parce que l'accord passé entre les parties est flou.

Un cahier des charges (SOW) vague engendre des problèmes prévisibles : « encore une petite fonctionnalité », un accès aux données mal défini, aucun critère de recette sur les livrables, et un débat interminable sur qui assure la maintenance.

Ce que vous allez apprendre

• Les sections que tout SOW IA doit inclure
• Comment rédiger des critères de recette pour des workflows propulsés par des LLM
• Les limites de périmètre qui évitent la dérive de périmètre (scope creep)
• Les clauses de sécurité et de périmètre des données attendues par les achats
• Un modèle de SOW réutilisable pour projets IA

L'essentiel

Un SOW solide pour un projet IA définit des limites de périmètre, des critères de recette et une règle de gestion des changements. Pour les workflows basés sur des LLM, les critères de recette doivent inclure un jeu d'évaluation, des seuils de qualité, des exigences de refus/citation, et un plan de retour arrière (rollback). Les achats ont également besoin de règles claires sur la gestion des données, la propriété intellectuelle et les conditions de support. Un bon SOW transforme un projet IA en système de livraison mesurable.

Modèle de SOW pour projet IA : les sections non négociables

Un SOW compatible avec les exigences achats doit contenir :

• Énoncé du problème et définition du workflow
• Périmètre inclus / périmètre exclu
• Périmètre des données et exigences de sécurité
• Critères de recette et plan d'évaluation
• Cadence de livraison et jalons
• Gestion des changements et conditions commerciales
• Attentes en matière de transfert et de support

Si l'une de ces sections manque, le projet dérivera.

Périmètre inclus / exclu (en langage clair)

Le langage utilisé pour décrire le périmètre doit être compréhensible par une partie prenante non technique.

Exemples d'énoncés de périmètre utiles :

• Inclus dans le périmètre : « Synthèse des tickets de support pour les agents internes, avec citations de l'historique du ticket. »
• Hors périmètre : « Réponses de support client entièrement automatisées, sans revue humaine. »

Une règle pratique :

Une demande est dans le périmètre si elle correspond au backlog convenu et ne modifie ni le périmètre des données, ni le périmètre de sécurité, ni les critères de recette.

Critères de recette pour les workflows propulsés par des LLM

N'acceptez pas un simple « ça semble bien ».

Utilisez des critères mesurables :

• Qualité : seuil de précision sur un jeu de test
• Sécurité : comportement de refus pour les sujets restreints
• Ancrage (grounding) : exigences de citation lorsque des sources existent
• Latence : temps de réponse acceptable
• Repli (fallback) : ce qui se passe lorsque le niveau de confiance est faible

Formalisez l'exigence de jeu d'évaluation. Même un petit ensemble (20 à 50 exemples) suffit à éviter des régressions silencieuses.

Exemples : des critères de recette qui résistent à l'examen

Les fondateurs et les équipes achats veulent généralement la même chose : moins de débats à la fin. Le moyen le plus rapide de réduire ces débats est d'intégrer des exemples directement dans le SOW.

Voici quelques modèles que vous pouvez reprendre et adapter :

Exemple A : workflow de synthèse

• Entrées : uniquement les tickets et notes internes (systèmes explicitement listés)
• Format de sortie : synthèse à puces + « prochaines étapes » + indicateur de confiance
• Seuil de qualité : sur un jeu d'évaluation de 30 tickets réels, les synthèses doivent inclure tous les champs requis dans au moins 27 cas sur 30
• Seuil de sécurité : aucun identifiant client ne doit apparaître dans la synthèse produite
• Repli : si des champs requis sont manquants, le workflow bascule vers une revue humaine plutôt qu'une publication automatique

Exemple B : workflow de classification/routage

• Format de sortie : libellé de catégorie + justification courte + indicateur d'escalade
• Seuil de qualité : seuil de précision minimal sur le jeu d'évaluation, plus une revue de la matrice de confusion pour les 3 principaux types d'erreurs
• Traçabilité : chaque sortie enregistre la version des règles/du prompt et l'identifiant de l'entrée (jamais l'entrée sensible brute)
• Repli : les cas inconnus ou à faible confiance sont routés vers une file par défaut

Exemple C : assistant de connaissance interne (RAG)

• Périmètre des données : uniquement les documents internes approuvés ; exclusions explicites (RH, juridique, exports clients, etc.)
• Permissions : l'assistant doit respecter les contrôles d'accès existants ; pas d'« index unique pour tout le monde »
• Ancrage : les réponses doivent citer les documents internes lorsqu'ils sont disponibles, et l'assistant doit refuser de répondre lorsque les sources manquent ou que l'accès est refusé
• Contrôle de non-régression : évaluation exécutée après chaque changement significatif (paramètres de récupération, indexation, prompt, corpus documentaire)

L'objectif n'est pas d'écrire un roman. L'objectif est de supprimer toute ambiguïté sur ce que signifie « bon ».

Périmètre des données et clauses de sécurité

C'est le point sur lequel les équipes achats et sécurité vont se concentrer.

Incluez :

• Sources de données autorisées
• Sources de données restreintes
• Exigences de contrôle d'accès (moindre privilège)
• Politique de journalisation (anonymisation, durée de conservation)
• Risque fournisseur et dépendances tierces — consultez notre guide des clauses de cybersécurité pour des formulations contractuelles standards

Si le workflow touche à des données personnelles (PII), ajoutez des règles explicites sur ce qui peut être stocké et ce qui doit rester éphémère.

Gestion des changements (l'interrupteur qui stoppe la dérive de périmètre)

La gestion des changements n'a pas besoin d'être lourde.

Définissez :

• Un canal d'entrée unique
• Un tri hebdomadaire
• Une règle de déclenchement : à partir de quand une demande devient un nouveau périmètre

Cela évite qu'un « encore une petite intégration » ne se transforme en projet caché.

Ajoutez un formulaire de demande de changement simple (pour que les évolutions de périmètre restent courtoises)

La dérive de périmètre devient source de conflit lorsque personne ne voit l'arbitrage en jeu. Une demande de changement le rend visible.

Ajoutez-le en annexe et gardez-le léger :

Change request

Requested change:

Why it’s needed (business reason):

Does it change any of these?
- Data boundary (yes/no)
- Security boundary (yes/no)
- Acceptance criteria (yes/no)
- Timeline (yes/no)

Impact estimate:
- New deliverables:
- Timeline impact:
- Cost impact:

Decision:
- Approved / Rejected / Deferred
- Approved by:
- Date:

Cette page unique évite le débat du « on pensait que c'était inclus » qui abîme les relations.

Jalons, paiements et support (soyez explicite)

Les achats comme les fondateurs veulent la même chose : moins de surprises. Le moyen le plus sûr de créer des surprises est de laisser la « mise en production » et le « support » indéfinis.

Incluez :

• Des jalons alignés sur de vrais livrables (pas des phases vagues)
• Un échéancier de paiement lié à ces jalons
• Une courte période de garantie (correctifs vs nouveau périmètre)
• Des attentes de support post-lancement (délai de réponse, chemin d'escalade)

Si vous sautez cette étape, vous finirez par renégocier au moment le plus stressant du projet : juste après le lancement, lorsque les parties prenantes veulent des changements et que l'équipe est encore en train de stabiliser le workflow.

Un modèle simple :

• Jalon 1 : plan cadré + critères de recette + jeu d'évaluation
• Jalon 2 : pilote livré + plan de retour arrière + démonstration
• Jalon 3 : dossier de transfert + formation + revue de préparation opérationnelle

Cela permet de garder les échanges entre l'équipe de livraison et les achats ancrés dans des résultats concrets.

Ce que les achats surveillent en silence

Pour un fondateur, les achats peuvent ressembler à un mur. Pour les achats, les fondateurs peuvent ressembler au chaos. Le SOW est l'endroit où l'on met les deux parties à l'aise.

Les éléments qui réduisent les frictions :

• Une propriété claire : un responsable identifié de chaque côté. Les achats détestent « cinq parties prenantes, aucun responsable ».
• Dépendances tierces : listez-les explicitement. Une surprise tardive dans le projet déclenche des revues de risque et des retards.
• Attentes de support : définissez ce qui se passe après le lancement. « Nous serons disponibles » n'est pas un plan.
• Propriété intellectuelle et confidentialité : restez sobre et clair. L'ambiguïté sur ce point ralentit tout le reste.

Même si votre client est petit et n'a pas de fonction achats, vous y gagnez : la même clarté évite la dérive entre parties prenantes internes.

Que mettre en annexe (pour que le corps du SOW reste lisible)

Une erreur fréquente consiste à tout entasser dans le corps du SOW jusqu'à le rendre illisible. Gardez le SOW court et placez les détails en annexes.

Des annexes qui fonctionnent bien pour les projets IA :

• Glossaire : définissez des termes comme « jeu d'évaluation », « périmètre des données », « PII », « retour arrière » et « demande de changement ». Cela évite les débats sémantiques.
• Annexe sécurité : règles de journalisation, durée de conservation, contrôles d'accès, liste des fournisseurs/outils et processus de signalement d'incident.
• Exemples de tests de recette : quelques cas de test représentatifs et la grille d'évaluation. Pas l'intégralité du jeu de données, juste assez pour rendre le mot « bon » concret.
• Liste des livrables de transfert : runbook, cartographie des responsabilités, journal des décisions, et procédure d'exécution de la suite d'évaluation. (Voir notre guide de transfert pour la liste complète.)

Cela aide aussi les achats : ils peuvent transmettre les annexes à la sécurité ou à l'IT sans obliger chaque partie prenante à lire l'intégralité du document.

Le squelette du SOW

Utilisez ce squelette et complétez les blancs. Restez concis.

Projet :
Workflow :
Responsable côté client :
Responsable de la réalisation :

Inclus dans le périmètre :
-

Exclu du périmètre :
-

Périmètre des données :
- Sources autorisées :
- Sources restreintes :
- Contrôles d'accès :

Critères d'acceptation :
- Jeu et calendrier d'évaluation :
- Seuil de qualité :
- Exigences de sécurité et de citation des sources :
- Objectif de latence :
- Repli et retour arrière :

Plan de réalisation :
- Jalons :
- Rythme des démonstrations et du tri :

Gestion des changements :
- Canal de réception des demandes :
- Critère de déclenchement d'un nouveau périmètre :

Passation :
- Procédures d'exploitation :
- Responsabilités et assistance :

Conditions commerciales :
- Échéancier de paiement :
- IP and confidentiality:
- Third-party dependencies:

Un SOW est un accélérateur de livraison

Un bon SOW réduit l'ambiguïté, protège les deux parties et rend la valeur mesurable. Si vous avez besoin d'aide pour structurer un accord de projet IA, parlons-en.