Beaucoup de contenus consacrés à l’IA s’arrêtent encore à la gouvernance ou à la conformité. Or ces principes ne deviennent réellement opérants que lorsqu’ils sont traduits dans les processus de la DSI, en particulier dans les processus projet, à travers des livrables dédiés, des validations explicites et une recette adaptée. Cette intégration doit intervenir rapidement afin de sécuriser les choix structurants sans réduire la valeur attendue des projets IA ni ralentir inutilement leur mise en œuvre.
Les travaux menés par Ana ESTEVES, accompagnée de Florence HOUESSOU, ont ainsi conduit à une première proposition de mise à jour des processus projet en cycle en V et en Agile. L’objectif n’est pas de créer une méthode parallèle réservée à l’IA, mais de faire évoluer les méthodes existantes afin d’intégrer les exigences propres aux modèles, aux données, aux sources documentaires, aux prompts et aux agents connectés au système d’information.
Faire évoluer le cycle en V dès l’expression du besoin
Un projet IA ne peut pas être traité comme un projet applicatif classique auquel une recette spécifique serait simplement ajoutée en fin de parcours. Les choix relatifs aux données, aux sources, au modèle, au fournisseur et au niveau d’autonomie déterminent directement le niveau de risque du projet.
Dès l’expression du besoin, une fiche d’opportunité IA doit donc préciser la finalité du cas d’usage, les utilisateurs concernés, le type d’IA envisagé et le niveau d’autonomie attendu. Cette première étape permet d’éviter qu’un assistant influençant une décision ou accédant au système d’information soit traité comme un simple outil de productivité.
La phase de qualification doit ensuite déterminer la criticité du projet. Elle examine notamment la sensibilité des données, les décisions susceptibles d’être influencées, les connexions prévues avec le SI et les actions que la solution pourra préparer ou exécuter. Cette classification permet d’identifier les exigences réglementaires applicables ainsi que les validations attendues du métier, de la DSI, du RSSI, du DPO ou des fonctions Risques
Transformer les risques IA en exigences de conception
Le cadrage doit intégrer une analyse de risques IA, en complément de l’analyse de risques SSI. Celle-ci doit couvrir les risques propres au cas d’usage, comme les hallucinations, l’exposition de données sensibles, les erreurs de droits dans un RAG, les attaques par prompt injection, la dérive du modèle ou l’exécution d’une action non maîtrisée par un agent.
Les mesures de traitement issues de cette analyse doivent ensuite être transformées en exigences projet. Chaque exigence doit être rattachée à un responsable, à un livrable et à un jalon de validation afin d’éviter qu’elle reste déclarative ou qu’elle soit reportée à la recette.
Lors de la conception, le dossier d’architecture doit notamment préciser les modèles utilisés, les API appelées, les règles d’accès, la journalisation et les modalités de supervision humaine. Pour un RAG, un registre des sources documentaires doit identifier les documents autorisés, leurs propriétaires, leur niveau de confidentialité et leur fréquence de mise à jour.
La conception doit également prévoir le fonctionnement en mode dégradé. Le projet doit définir ce qui se passe lorsque le modèle ou une source n’est plus disponible, lorsque la réponse n’atteint pas le niveau de confiance attendu ou lorsque le comportement de la solution devient anormal.
Maîtriser les évolutions du modèle et de ses composants
La phase de développement, de configuration et de MLOps doit garantir la traçabilité des modèles, des prompts structurants, des sources et des paramètres de configuration. Une évolution du modèle ou d’un prompt peut modifier les résultats sans changement visible du code applicatif.
Ces composants doivent donc être versionnés, testés et approuvés. Le projet doit également sécuriser les secrets techniques, les pipelines de déploiement et les droits permettant de modifier les configurations.
Une capacité de retour arrière doit enfin permettre de restaurer rapidement une version maîtrisée lorsque la fiabilité se dégrade, qu’une vulnérabilité est détectée ou qu’un changement fournisseur produit un comportement inattendu.
Mettre en place une véritable recette IA
La recette d’un projet IA ne peut pas se limiter à vérifier que la fonctionnalité répond à une commande. Elle doit démontrer que la solution produit des réponses suffisamment fiables, utilise les bonnes sources et respecte les droits des utilisateurs.
La stratégie de tests doit couvrir les hallucinations, les demandes ambiguës, les sources contradictoires, la robustesse des réponses et la capacité du système à ne pas répondre lorsque les informations disponibles sont insuffisantes.
Pour un RAG, les tests doivent confirmer que les réponses reposent sur des sources autorisées, à jour et accessibles à l’utilisateur. Le système ne doit pas restituer une information à laquelle l’utilisateur n’aurait pas accès directement dans la source d’origine.
Pour un agent IA, la recette doit également contrôler les actions qu’il peut préparer ou exécuter. Les actions sensibles doivent être limitées, journalisées et soumises à une validation humaine adaptée. Une réponse correcte ne suffit pas si l’agent peut ensuite intervenir au-delà de son périmètre autorisé.
Les scénarios exécutés, les résultats obtenus et les anomalies identifiées doivent être conservés dans un rapport de recette IA, afin de disposer de preuves exploitables lors de la décision de mise en production.
Fonder le Go/No Go sur le niveau réel de maîtrise
La mise en production ne doit pas être décidée sur la seule base de la performance fonctionnelle ou de l’absence d’anomalies techniques bloquantes.
Le dossier de Go/No Go doit intégrer les résultats de la recette IA, le respect des exigences de sécurité et la maîtrise des habilitations. Les anomalies bloquantes doivent être levées, tandis que le risque résiduel doit être formalisé et accepté par l’autorité disposant du niveau de responsabilité approprié.
Le dispositif de supervision doit également être opérationnel avant la mise en production. Les indicateurs de fiabilité, les incidents, les alertes de sécurité et les évolutions du modèle doivent pouvoir être suivis. Les conditions conduisant à limiter, suspendre ou retirer la solution doivent enfin être définies.
Intégrer les mêmes exigences dans les démarches Agile
Dans une démarche Agile, les exigences IA ne doivent pas être regroupées dans une validation finale avant la release. Elles doivent être intégrées dans le backlog et suivies tout au long des itérations.
Les Epics et les User Stories doivent comporter des critères relatifs aux données, aux sources, aux droits et à la supervision humaine. La Definition of Ready doit confirmer que les principaux risques et les dépendances sont identifiés avant le lancement du développement.
La Definition of Done doit, quant à elle, intégrer l’exécution des tests IA et la disponibilité des preuves. Les tests de fiabilité, de robustesse et de sécurité doivent être rejoués lorsque le modèle, les prompts, les sources ou les configurations évoluent.
Chaque release doit enfin faire l’objet d’un arbitrage proportionné au niveau de changement et au risque résiduel associé. L’Agile ne réduit donc pas l’exigence de maîtrise, mais la rend plus fréquente et mieux intégrée au déroulement du projet.
Préserver la valeur des projets IA
Cette évolution ne vise pas à ajouter une couche documentaire ou à ralentir les initiatives. Elle permet de sécuriser plus tôt les décisions structurantes, de réduire les corrections tardives et de rendre les arbitrages de mise en production plus solides.
Elle crée également un langage commun entre les métiers, les équipes projet, la DSI, le RSSI, le DPO et les fonctions Risques. Chaque acteur peut ainsi s’appuyer sur des livrables partagés, des critères de validation explicites et des preuves directement exploitables.
Un projet IA peut être techniquement fonctionnel tout en restant insuffisamment maîtrisé. Une réponse apparemment pertinente peut être erronée, un assistant peut accéder à des sources qui dépassent le besoin réel et un agent peut disposer de droits excessifs. Une évolution du modèle, des prompts ou des données peut également modifier le comportement de la solution sans changement visible du code applicatif.
Ces spécificités doivent donc être intégrées dès l’amont dans les processus projet. À défaut, les risques sont découverts lorsque l’architecture est déjà définie, que les données sont intégrées et que les choix fournisseurs deviennent difficiles à remettre en cause. Leur correction est alors plus coûteuse et peut retarder la mise en production, tandis que la décision repose sur une appréciation incomplète du niveau réel de maîtrise.
Adapter les processus projet à l’IA permet ainsi de préserver la valeur des usages tout en maintenant le niveau attendu de sécurité, de conformité et de maîtrise opérationnelle.