Lecture rapide
Ce qu’il faut retenir
- Décrire le résultat attendu avant l'architecture.
- Donner des volumes et des exemples représentatifs.
- Écrire les critères de recette et les cas d'échec.
- Inclure exploitation, sécurité, maintenance et réversibilité.
Imposer une solution avant d'avoir cadré le besoin
Demander un chatbot ou un agent IA ne décrit ni l'utilisateur, ni le processus, ni la décision. Deux prestataires peuvent répondre au même mot avec des périmètres totalement différents. Commencez par la situation, les acteurs, les volumes et le résultat attendu.
Une préférence technique peut être mentionnée comme contrainte ou hypothèse. Elle ne doit pas masquer les alternatives possibles : simplification, règle classique, recherche documentaire ou changement d'organisation.
Rester vague sur les données et les volumes
Les expressions beaucoup de documents ou plusieurs utilisateurs empêchent d'estimer le stockage, les licences, les performances et les tests. Donnez des ordres de grandeur, les pics, les formats, les langues et un échantillon anonymisé lorsque c'est possible.
Précisez aussi la qualité, les doublons, les champs manquants et le propriétaire de chaque source. L'accès à la donnée est une partie du projet, pas une formalité à traiter après le devis.
- Volume moyen et maximum.
- Historique disponible.
- Formats et exemples de cas limites.
- Droits d'accès et sensibilité.
- Fréquence des mises à jour.
Oublier les critères d'acceptation
Sans jeu de tests et seuils, la recette devient une discussion subjective. Définissez ce qui sera mesuré, sur quels exemples, par qui et avec quelle tolérance. Prévoyez les faux positifs, les faux négatifs et les situations où le système doit s'abstenir.
Ajoutez une référence actuelle : temps, qualité, délai ou taux de reprise. Le projet doit améliorer une situation connue, pas seulement produire une fonctionnalité.
Limiter le document à la livraison initiale
Un système IA demande une exploitation : suivi des coûts, incidents, changements de données, mises à jour, sécurité et assistance. Le cahier des charges doit préciser qui surveille, qui corrige, comment les versions sont déployées et comment les données sont restituées en fin de contrat.
Demandez les coûts récurrents, les limites de support et les conditions de réversibilité. Un prix initial attractif ne suffit pas à juger le coût sur trois ans.
Questions fréquentes
Questions fréquentes
Un cahier des charges IA doit-il être très technique ?
Non. Il doit surtout être précis sur le besoin, les données, les contraintes, les tests et les responsabilités. Les choix techniques peuvent être proposés et justifiés par l'intégrateur.
Peut-on demander une phase de cadrage dans la consultation ?
Oui. Lorsque des inconnues subsistent, une phase courte de cadrage peut constituer le premier lot, avec ses propres livrables et une décision avant réalisation.
Comment comparer deux réponses très différentes ?
Ramenez-les aux mêmes unités : périmètre couvert, hypothèses, données, intégrations, critères de recette, coûts initiaux et récurrents, délais, support et risques restant à votre charge.