12 points de contrôle avant de lancer un projet IA générative.

Bloc 1 — La valeur métier.

1. La tâche est nommée et mesurée aujourd'hui. Un processus précis (traitement d'une demande, recherche documentaire, préparation d'un comité), avec un temps ou un coût actuel constaté. Une mesure initiale permet une comparaison explicite après le pilote.

2. Le volume justifie l'investissement. La fréquence de la tâche, la qualité attendue et la valeur du résultat sont mises en regard du coût de construction et d’exploitation. Les hypothèses de gain restent à vérifier.

3. L'IA générative est la bonne réponse. Si la tâche est purement mécanique et stable, une automatisation classique ou un workflow suffit. L'IA générative apporte de la valeur quand il faut lire, interpréter ou rédiger en langage naturel.

4. Un utilisateur pilote est identifié. Une équipe nommée, disponible pour tester et donner du retour chaque semaine. Un projet sans utilisateur désigné reste une démo.

Bloc 2 — Les données et les documents.

5. Le corpus existe et son propriétaire est connu. Les documents ou données nécessaires sont accessibles, et une personne peut autoriser leur usage.

6. La version de référence est identifiable. Pour chaque document, on sait quelle version fait foi. Des versions obsolètes peuvent conduire à des réponses inadaptées ; les dates et règles de sélection doivent être explicites.

7. Les droits d'accès sont hérités. Le système respecte les permissions des sources : un utilisateur ne doit pas obtenir par l'IA une information qu'il ne peut pas lire directement.

Bloc 3 — La conformité (AI Act, RGPD, secteur).

8. La classification AI Act est faite. La finalité et le rôle des acteurs sont examinés avec les équipes compétentes pour déterminer les obligations applicables. Les systèmes d’évaluation du risque et de tarification des personnes physiques en assurance vie et santé font notamment l’objet d’un encadrement spécifique. Consulter le calendrier officiel de l’AI Act : il est progressif.

9. Le point de contrôle humain est dessiné. On sait qui valide quoi, à quelle étape, avant qu'une réponse ou une action n'ait d'effet. Le niveau de contrôle est adapté aux conséquences de l’usage et aux obligations applicables ; sa présence seule ne garantit pas la conformité.

10. L'hébergement et les sous-traitants sont qualifiés. Localisation des données, modèles servis en interne ou chez un fournisseur évalué, DPA signé si nécessaire. Les équipes sécurité et le DPO sont informés dès le cadrage.

Bloc 4 — L'évaluation et la gouvernance.

11. Un jeu d'évaluation existe avant le développement. Des cas représentatifs, des erreurs possibles et des réponses attendues sont définis avec les utilisateurs. Le volume du jeu dépend du périmètre et des risques. C'est l'outil qui mesurera la qualité, aujourd'hui et à chaque évolution du système.

12. Les rôles sont écrits. Un RACI simple : qui décide du périmètre, qui valide la qualité, qui exploite, qui arrête le système si nécessaire. Cette clarification rend les responsabilités et les points d’escalade explicites.

Comment utiliser cette checklist.

Télécharger les 12 points en Markdown ↓

Pour chaque point, noter les éléments disponibles, les questions ouvertes, un responsable et une prochaine étape. La décision de lancer le pilote dépend de la nature des risques encore ouverts, pas d’un score automatique. Cette checklist est un support de cadrage, pas une certification de conformité.

C'est précisément l'objet du format « diagnostic et feuille de route » : parcourir ces points avec vos équipes, scorer les cas d'usage et ressortir avec une proposition de périmètre, des critères de réussite et les risques documentés.