Cahier des charges d’un projet Claude sur mesure : quoi exiger, quoi laisser ouvert

Un cahier des charges de projet Claude sur mesure tient en sept rubriques : le problème chiffré, le périmètre des cas d’usage, les sources de données et leurs accès, les contraintes de la DSI, les critères d’acceptation sous forme de jeu de test, la propriété des livrables et le transfert aux équipes. Il ne fixe ni version de modèle, ni fine-tuning, ni nombre de prompts.

Il diffère d’un cahier des charges logiciel sur deux points. Le composant central, le modèle, n’est pas développé mais loué, et il change de génération sans demander votre avis. Et sa sortie n’est pas déterministe : la même question posée deux fois peut produire deux textes différents, ce qui interdit la recette « un cas, un résultat attendu ».

Ce que vous achetez n’est donc pas un modèle mais ce que nous appelons le Harness d’entreprise : les contextes, les compétences, les connecteurs et les garde-fous qui font qu’un Claude générique produit au standard de votre maison. C’est cette couche que le document doit décrire.

Que doit contenir un cahier des charges Claude que les modèles génériques oublient ?

Les quatre composants du Harness, chacun décrit comme un livrable avec un propriétaire. Les modèles génériques parlent de pipeline de données et de précision du modèle ; aucun ne nomme ces quatre objets, qui sont pourtant ce que vous paierez et maintiendrez.

• Contextes métier : la liste des documents de référence que Claude doit connaître sans qu’on les lui réexplique (offres, vocabulaire, conventions de rédaction), avec pour chacun un propriétaire et une fréquence de mise à jour.
• Skills par équipe : les compétences packagées attendues, décrites par leur sortie (une proposition commerciale au format maison, une revue de code aux standards internes), pas par la façon de les obtenir.
• Connecteurs : les systèmes que Claude doit lire ou modifier (CRM, wiki, dépôts, GED), en lecture ou en écriture, et le périmètre exact par équipe. Depuis la spécification MCP du 28 juillet 2026, un serveur de connecteur est un serveur de ressources OAuth 2.1 : exigez que les accès passent par votre fournisseur d’identité, avec des droits minimaux.
• Garde-fous : ce que Claude ne doit jamais faire ou lire, et qui le vérifie. Un garde-fou écrit dans une charte n’est pas un livrable ; implémenté dans l’architecture, il l’est.

Quelles contraintes de la DSI écrire noir sur blanc ?

Trois décisions que le prestataire ne peut pas prendre à votre place, parce qu’elles engagent votre conformité et votre budget : le cahier des charges est l’endroit où les écrire.

• Le canal d’accès : API directe d’Anthropic, Claude Platform on AWS, Amazon Bedrock, Google Cloud ou Microsoft Foundry. L’API directe ne propose aucune option de traitement en Union européenne ; un confinement européen passe par Bedrock ou Google Cloud. Le choix détermine qui est sous-traitant de vos données, et nous l’avons détaillé dans notre comparaison des cinq canaux d’accès à Claude.
• La rétention : sur les offres entreprise d’Anthropic, la conservation est indéfinie par défaut, ajustable par l’administrateur avec un plancher de 30 jours ; la rétention zéro s’active par organisation, après éligibilité. Si votre politique exige un délai, il doit figurer dans le document, pas dans un mail.
• Le plan et son mode de facturation : des sièges Team ou Enterprise pour les personnes, l’API pour les logiciels, souvent les deux. La question se règle avant la consultation, parce qu’elle change le chiffrage de fonctionnement.

Comment écrire des critères d’acceptation pour une sortie non déterministe ?

Par un jeu de test, pas par une démonstration. Pour chaque cas d’usage, le document fixe quelques dizaines de cas réels tirés de vos dossiers, la sortie attendue ou les critères qu’elle doit remplir, qui juge (un métier nommé, une grille, ou les deux) et le seuil de réussite en dessous duquel la livraison est refusée.

La recette porte sur l’échantillon entier, jamais sur le cas qui marche bien en réunion. C’est exactement la mécanique des évals de qualité des sorties IA : un jeu annoté, des juges, un score, rejoué à chaque modification du Harness.

Ajoutez une clause de non-régression : à chaque nouvelle génération de Claude, le même jeu de test est rejoué, par une personne nommée, dans un délai fixé. Un fournisseur qui refuse cette clause vend un prompt, pas un système.

Que faut-il laisser hors du cahier des charges ?

Trois exigences fréquentes coûtent cher sans rien protéger.

• La version du modèle. Un Harness correctement conçu est indépendant de la génération de Claude : contextes, skills et garde-fous restent valides au changement de modèle. Figer une version dans le contrat, c’est s’interdire la migration que vos équipes devraient savoir faire seules.
• Le fine-tuning. Dans la quasi-totalité des cas d’entreprise, les contextes métier et les connecteurs obtiennent le résultat visé, un modèle qui connaît l’entreprise, tout en restant modifiables à tout moment. Le fine-tuning fige le modèle et complique chaque migration ; s’il est demandé, exigez qu’on vous prouve d’abord que le contexte ne suffit pas.
• Le nombre de prompts livrés. Un prompt n’est pas une unité d’œuvre. Ce qui se compte, ce sont les cas d’usage couverts et les cas de test qui passent.

Qui possède quoi à la fin, et qui sait le modifier ?

La rubrique la plus souvent absente, et celle qui décide de votre dépendance au prestataire. Le document liste les objets livrés et leur régime : les données sources restent les vôtres, les contextes, skills, l’architecture et la documentation doivent être livrés dans vos dépôts, sous votre contrôle, avec le droit de les modifier.

Puis le transfert. Le cahier des charges nomme les personnes de votre équipe qui sauront, à la fin, modifier un contexte, ajouter un skill et rejouer le jeu de test, et prévoit le temps de formation nécessaire. Dans notre méthode, c’est une semaine entière sur trois ; un cabinet de conseil a mis Claude dans tous ses process en trois semaines parce que cette semaine existait.

Enfin la réversibilité : une archive complète (code, configurations, contextes, jeux de test, documentation) qu’un tiers pourrait reprendre. Sans elle, la propriété est un mot dans le contrat.

Prochaine étape : écrire le problème et le jeu de test avant de consulter

Deux rubriques se rédigent sans aucun prestataire et conditionnent toutes les autres : le problème chiffré (combien d’heures, de dossiers, de délais aujourd’hui) et le premier jeu de test tiré de vos dossiers réels. Avec ces deux pages, les réponses des prestataires deviennent comparables ; sans elles, vous comparerez des promesses.

Les cinq autres rubriques se remplissent en une semaine d’audit sur site, cartographie des données et des cas d’usage comprise : c’est la première des trois semaines de notre programme Claude sur mesure. Si vous préférez instruire le document avant toute consultation, cette semaine d’audit se mène aussi seule, sans engagement sur la suite.