Table of Contents
Votre POC IA est lancé, les voyants sont au vert et l’intérêt interne est à son comble. Mais attention au mirage : c’est ici que commence la phase la plus risquée.
Pour beaucoup d’organisations, le passage du prototype à la production se transforme en impasse. Réussir ce virage exige de quitter le « bac à sable » pour construire une solution fiable, scalable et cyber-sécurisée.
Chez Yogosha, plateforme de sécurité offensive, nous avons traversé ce cycle pour donner naissance à notre agent de triage assisté. Nous avons appris qu’il faut d’abord savoir cadrer l’inconnu pour extraire de la valeur, avant de pouvoir transformer l’essai en une solution robuste et conforme. Comment piloter son POC sans s’y perdre ? Comment passer à l’échelle sans sacrifier la sécurité ?
Nous vous partageons ici les coulisses de notre retour d’expérience : comment piloter l’expérimentation avec agilité et industrialiser en sécurisant chaque étape.
I. Du POC à la valeur : notre retour d’expérience pour éviter la dérive
À partir de quand un POC génère-t-il de la valeur ? Comment maîtriser sa temporalité et son périmètre ? Quand doit-on s’arrêter ? La valeur doit-elle impérativement se traduire par une livraison ? Nous partageons ici notre expérience pour éclaircir ces questions.
Le POC, c’est une aventure, mais elle est associée à deux risques majeurs : la dérive vers la production et l’investissement excessif dans une preuve de concept sans débouché concret. Voyons comment notre équipe a appris à naviguer pour éviter ces écueils.
Comment cadrer l’inconnu de la R&D ?
POC rime avec R&D et, par nature, avec l’inconnu. Comment encadrer efficacement un sujet encore flou ?
Nous avons appris qu’il est absolument nécessaire de définir pour chaque POC un objectif clair, une Definition of Done précise, et surtout des non-objectifs pour établir un cadre rigoureux. Cela permet à toute l’équipe de s’y référer et de s’assurer de ne pas dévier du cap initial. C’est pourquoi nous trouvons essentiel d’assigner une échéance temporelle claire à sa finalisation.
Une fois l’attente définie, il reste à tracer le chemin pour y parvenir.
L’expérimentation et le droit à l’erreur
Puisqu’un POC est une expérimentation, nous avons accepté qu’il ne faille pas chercher à tout définir d’emblée. Il n’y a pas de spécifications rigides ni d’échéances précises. Contrairement à un projet de développement itératif, nous nous sommes donnés le droit d’accepter l’erreur, d’expérimenter, de faire des retours en arrière et de construire le chemin de manière progressive.
Cette approche encourage la créativité et requiert plus de liberté pour progresser rapidement. S’il est crucial de ne pas se limiter, il faut garder à l’esprit que le respect du cadre de sécurité est non négociable, surtout dans un secteur aussi sensible que le nôtre.
Étant donné que la R&D et les POC ne sont pas des activités courantes dans toutes les équipes, nous avons trouvé pertinent de s’appuyer sur la méthodologie et les processus éprouvés de l’équipe existante (ShapeUp). Nous nous efforçons de maintenir les rituels, les temps d’échange et l’organisation en place pour ne pas déstabiliser le collectif.
Leçons clés : la confrontation rapide et le rôle du métier
Notre principale leçon : il est essentiel de confronter le POC à la réalité le plus rapidement possible et d’éviter d’itérer excessivement sur des prompts basés sur des données d’entrée trop spécifiques. Nous avons vu qu’il est facile de passer des heures à modifier le prompt pour optimiser le résultat, au risque de l’adapter inconsciemment à l’attente. L’établissement rapide d’évaluations permet de se confronter à un volume de données important et pertinent, et ainsi de valider rapidement la direction à prendre.
Travailler avec les équipes Métier constitue un enjeu en raison de leurs priorités et disponibilités. L’un des apprentissages clés de notre expérience est de ne pas chercher à intégrer les équipes Métier à toutes les étapes du POC. Même si elles détiennent la connaissance nécessaire, le Métier est souvent accaparé par le RUN et dispose d’une bande passante limitée. Nous trouvons plus efficient de les solliciter sur des sujets précis, avec un cadre et un périmètre clairs et bien définis, pour maximiser leur impact sans les épuiser.
En somme, l’objectif d’un POC n’est pas la livraison en production, mais bien de confirmer la faisabilité d’un projet et son intérêt auprès des utilisateurs. On peut tout à fait communiquer sur les résultats d’un POC sans que rien ne soit mis en production : l’apprentissage est, en soi, une valeur business.
Une fois que la valeur business est validée et que le cadre de l’expérimentation est maîtrisé, une question cruciale se pose : est-on prêt pour la réalité du terrain ? Si le POC nous a permis d’apprendre sans risque, la “feature”, elle, devient une promesse faite à nos clients. Nous devons quitter le bac à sable pour entrer dans l’arène de l’industrialisation.
II. Comment passer du POC à la feature en assurant la sécurité ?
Une fois que le POC a prouvé sa valeur, l’excitation est à son comble : nous tenons enfin notre agent de triage capable de détecter les out-of-scope et les doublons. On a alors envie de presser immédiatement sur le bouton “Prod”.
Mais c’est précisément là qu’il faut garder la tête froide. Notre mantra a été clair dès le début : on ne passe jamais un POC tel quel en production. Pourquoi ? Parce qu’un POC est une exploration, alors qu’une feature est un engagement de sécurité et de fiabilité envers nos clients. Voici comment nous avons structuré cette transition critique.
La confrontation aux risques : le moment de vérité
Avant de sortir la version finale, nous nous sommes réunis pour une analyse de risques approfondie, un exercice que nous pratiquons lors du cadrage de chaque fonctionnalité. Son but est simple : lever les incertitudes pour éviter que le projet ne déraille.
Plusieurs catégories de risques ont émergé : le légal, la sécurité, les coûts, l’usage, la fiabilité du workflow ou encore la pertinence des recommandations faites par l’IA.
Dé-risquer le volet légal
Dé-risquer le volet légal a été notre priorité pour valider notre périmètre d’action. Nous avons balayé trois piliers :
- Les données : Où transitent-elles et comment sont-elles protégées ?
- Les modèles d’IA : Quelle est leur fiabilité ? Sont-ils opaques ?
- La réglementation : Sommes-nous en phase avec l’AI Act et le RGPD ?
Une question nous a particulièrement animés : celle du chiffrement et du SecNumCloud. Est-ce qu’on a le droit de ne pas l’être ? Est-ce qu’on le souhaite ?
Avant même de déployer une version Beta, il est primordial d’offrir une transparence totale à nos clients pilotes sur le modèle utilisé et la gestion de leurs données.
Et une mise à jour de nos documents légaux est bien sûr un pré-requis au déploiement d’une fonctionnalité IA dans notre plateforme.
💡Le regard des avocats : sécuriser le terrain légal
Quelles sont les bonnes pratiques pour intégrer une feature IA dans son produit ?
L’intégration d’une fonctionnalité d’IA dans un produit doit être gérée à travers des prismes technique, légal et réglementaire.
L’objectif principal est de sécuriser la provenance de l’IA et des données utilisées. Cela passe par un renforcement des protections contractuelles et légales pour atteindre la conformité réglementaire, en particulier celle imposée par l’AI Act.
| Domaine | Bonnes pratiques clés |
| Technique & Légal | Modèle d’IA : Identifier clairement l’origine du modèle (propriétaire vs. tiers). |
| Contractuel | Licences & Sous-licence : Vérifier les conditions de licence et s’assurer que les droits de sous-licence sont correctement transférés et autorisés. |
| Contractuel | Encadrement Contractuel : Systématiser l’intégration de clauses spécifiques encadrant l’utilisation des modèles d’IA dans les contrats. |
| Conformité & Légal | Réglementation : Identifier et assurer la conformité avec toutes les réglementations applicables (ex: RGPD, AI Act). |
| Réglementaire (AI Act) | Cartographier les systèmes d’IA : Déterminer si le Système d’IA (SIA) entre dans une catégorie spécifique (notamment “haut risque”) de l’AI Act et établir un plan de mise en conformité. |
| Opérationnel | Limitations : Connaître le périmètre d’utilisation du modèle et ses éventuelles limitations. |
| Fournisseurs | Questionnaire Fournisseur : Intégrer des questions spécifiques sur l’IA (sécurité, conformité, normes, infrastructure, etc.) dans les questionnaires pré-contractuels. |
| Données | Maîtriser des jeux de données : Utiliser des jeux de données strictement encadrés, tant en interne que contractuellement, pour l’entraînement et l’inférence. |
Sécuriser le volet technique
Évoluant dans le secteur de la cybersécurité, le risque technique est pour nous un sujet non négociable. Cette vigilance s’exerce dès la phase de développement du POC : grâce à l’expertise de nos équipes, nous avons fait une première phase de tests de résistance et de sécurité. C’est d’ailleurs cette rigueur qui nous a permis d’identifier et de patcher, dès la phase de développement, une faille de type Prompt Injection.
Fidèles à nos processus de release, nous ne laissons rien au hasard : chaque évolution majeure est systématiquement soumise à un pentest avant sa mise en production. Pour notre agent de triage IA, nous avons décidé d’aller plus loin en sollicitant des chercheurs spécialisés en sécurité de l’IA. Leur mission : pousser le modèle dans ses retranchements pour nous garantir un niveau de protection optimal.
L’architecture : industrialiser sans perdre l’agilité
Une fois les risques cernés, se pose la question du choix de la stack technique, et de l’équilibre entre performance et coût.
Voici les questions que nous nous sommes posées :
- Conserve-t-on notre framework & la stack choisi pour le POC ? Si oui, comment l’industrialiser ? Et comment suivre les vulnérabilités de ces outils ?
- Souhaite-on versioner les prompts ? Faut-il les mettre à jour en direct ou suivre un cycle de release classique ?
- Part-on sur un module AI SaaS ou Self-hosted pour répondre à toutes les demandes possibles d’hébergement des données ?
- Comment optimiser les coûts ? Quels sont les coûts de maintenance et d’évolution ?
Notre équipe infrastructure a réalisé une étude interne pour définir l’architecture cible et estimer précisément la consommation de tokens par rapport traité et les coûts associés. Chaque option a été pesée pour garantir la sécurité des données et une maintenance soutenable sur le long terme.
L’expérience utilisateur : l’humain reste le maître à bord
Deux grandes questions se posent quant à l’intégration d’un service IA dans un outil :
- Comment et où configure-t-on le service IA ?
- Quel est son déclencheur ?
Pour l’intégration dans la plateforme Yogosha, notre philosophie a été la transparence et le contrôle. Nous avons conçu l’IA comme un assistant qui suggère, mais qui nécessite toujours une validation humaine. Rien ne se fait “dans le dos” de l’utilisateur.
Nos principes de conception:
- L’option “Opt-in”: Il nous semble primordial que chaque organisation puisse activer ou désactiver le service IA à tout moment. L’IA n’est jamais imposée, elle est proposée comme un outil d’aide à la décision. Pourquoi ce choix ? Respect de l’autonomie de l’utilisateur, conformité aux exigences réglementaires et construction progressive de la confiance.
- Le déclencheur automatique avec validation humaine: Pour le triage, nous avons lié l’IA à la réception des rapports. Dès qu’une vulnérabilité arrive, l’assistant se met au travail pour préparer le terrain au Security Program Manager. Mais la décision finale reste toujours humaine.
Le flux utilisateur :
- Réception d’un nouveau rapport de vulnérabilité
- L’IA analyse automatiquement le rapport (si le service est activé sur l’asset du client)
- Un commentaire privé est posté sur le rapport avec la suggestion de triage par l’IA
- Le Security Program Manager triage le rapport (acceptation ou rejet)
- Le résultat de triage réalisé par un humain est comparé à la suggestion réalisée par l’IA pour amélioration continue
Tester, Mesurer, Apprendre
Le POC confirme la viabilité ; la Beta, elle, doit confirmer la fiabilité. Avant de lancer cette étape, trois prérequis sont essentiels :
- Tester avec des données de production réelles pour mesurer la pertinence du workflow. Il faut savoir ce que l’on souhaite mesurer, sur quelles données, et éviter les biais dans les données d’entrée. Sur notre cas d’usage de triage assisté nous avons joué le workflow sur échantillon représentatif de plus de 300 rapports réels, issus de nos programmes Yogosha internes, déjà triés manuellement et clôturés.
- Mettre en place des évaluations pour monitorer le taux de succès du workflow. La mise en place d’évaluation permet d’être en capacité de mesurer l’usage, la pertinence, la fiabilité et réactivité de notre workflow, une fois celui-ci dans la main d’utilisateurs.
- Mettre en place de la métrologie côté infra afin de mesurer le nombre de tokens utilisés lors des requêtes pour optimiser les coûts d’usage de l’IA, et faire un suivi de la performance de la machine.
Enfin, notre conseil est de ne pas ouvrir les vannes d’un coup mais d’opter pour une ouverture progressive.
Nous avons commencé par des POCs ciblés avec des clients partenaires. Cela nous a permis de récolter un feedback métier irremplaçable : l’IA a beau être performante mathématiquement, seule la réalité du terrain confirme son utilité réelle.
Conclusion: l’industrialisation, un virage stratégique maîtrisé
Passer du POC à la mise en production n’est pas une simple formalité technique, c’est un virage stratégique. Pour que l’IA apporte une valeur durable, elle doit quitter le laboratoire pour rejoindre un cadre rigoureux où la sécurité, la conformité légale et l’expérience utilisateur convergent.
Notre aventure avec l’agent de triage nous a confortés dans une conviction : l’IA ne doit pas être une “boîte noire” automatisée, mais un assistant transparent sous contrôle humain. En intégrant les enjeux juridiques dès la conception et en soumettant nos modèles à des tests de sécurité intensifs, nous avons transformé une expérimentation prometteuse en un outil de confiance.
L’industrialisation de l’IA est un cycle continu. En gardant l’humain aux commandes et en avançant par étapes mesurables, vous ne vous contentez pas de suivre la tendance : vous bâtissez une innovation robuste, capable de résister à la réalité du terrain.
Le succès de votre prochain projet d’IA ne dépendra pas de la complexité de vos algorithmes, mais de la solidité de la structure que vous bâtirez autour d’eux.
Êtes-vous prêt à franchir le pas de l’industrialisation ?
💡 Takeaways : 5 clés pour passer votre agent IA en production
- La sécurité ne se négocie pas : Dans notre secteur, une faille peut avoir des conséquences critiques. L’approche « move fast and break things » n’a pas sa place ici.
- Le légal est un accélérateur, pas un frein : En impliquant nos juristes dès le départ, nous avons évité les blocages de dernière minute. La conformité (RGPD, AI Act) est un atout de conception, pas un obstacle.
- L’architecture doit anticiper l’échelle : Nos choix d’infrastructure nous ont permis de maîtriser les coûts dès le départ. Passer en production a été une question d’ajustement de puissance, pas de refonte complète.
- L’humain reste aux commandes : Concevoir l’IA comme un assistant et non comme un automate a été décisif. Nos utilisateurs font confiance au système parce qu’ils en gardent le contrôle.
- La progressivité est votre meilleure alliée : Le déploiement par phases successives nous a permis de corriger des biais qui auraient été problématiques à grande échelle.
Pour en savoir plus sur comment lancer votre dynamique IA; comment choisir vos cas d’usage, technologies et outils; et monter en compétences, nous vous invitons à parcourir nos autres articles ici:
Transformation IA en 3 mois: Comment créer le momentum avec l’approche QPQC
Pivot IA la tête dans le capot : cas d’usage, outils & budget
IA et triage de vulnérabilités : retour d’expérience sur notre POC d’assistance automatisée
