Faire examiner un projet IA avant d'engager le budget.

Ce que nous évaluons

ENBI réalise une revue indépendante du projet avant engagement. Nous mobilisons quatre dimensions possibles — données & technologie, droit & gouvernance, économie & stratégie, organisation & contrôle — sans les traiter comme quatre audits juxtaposés.

Seules les dimensions susceptibles de changer la réponse sont approfondies.

L'objectif est de comprendre comment elles se combinent et ce que cette combinaison change dans la décision d'investir.

1. Données & technologie — ce qui est promis peut-il réellement fonctionner dans votre contexte ?

Nous examinons notamment le problème que le projet cherche à résoudre, la valeur démontrée par le prototype ou les expérimentations, la disponibilité et la qualité des données, la représentativité du périmètre testé, les performances réellement observées, les cas non couverts et les limites connues, l'architecture envisagée, les dépendances à un modèle, une API, une infrastructure ou un fournisseur, et les conditions techniques du passage à l'échelle.

Une performance obtenue en démonstration n'est pas automatiquement reproductible en production. Et une technologie performante n'est pas nécessairement la bonne réponse au problème.

2. Droit & gouvernance — qu'est-ce que les contraintes juridiques changent réellement dans le projet ?

Nous ne partons pas d'une checklist de conformité. Nous examinons les règles lorsqu'elles modifient une hypothèse du projet, une responsabilité, une donnée utilisable ou une condition de déploiement — le RGPD et les droits sur les données, la qualification du système au regard de l'AI Act, les responsabilités entre fournisseur et déployeur, les risques de discrimination ou de traitement différencié, la traçabilité et la documentation, les conditions du contrôle humain, les obligations propres au secteur ou à l'organisation.

La bonne question n'est donc pas seulement « le projet est-il conforme ? » mais « qu'est-ce que cette contrainte change dans la technologie, les coûts, les responsabilités ou la décision d'investir ? »

3. Économie & stratégie — le projet crée-t-il suffisamment de valeur pour justifier ce qu'il engage ?

Nous reconstruisons le business case au-delà du seul coût d'achat : la valeur réellement attendue, les hypothèses utilisées pour calculer le ROI, le coût d'intégration, les données et travaux préparatoires nécessaires, les licences, API ou consommations de modèles, la maintenance et le réentraînement éventuel, la supervision et le contrôle humain, la formation et la conduite du changement, les coûts de migration et de sortie.

Autrement dit, nous regardons le coût complet — ou total cost of ownership (TCO) — et pas seulement le budget initial. Un ROI n'est défendable que si les hypothèses qui le produisent le sont aussi.

4. Organisation & contrôle — si la décision est GO, l'organisation peut-elle réellement la mettre en œuvre ?

Beaucoup de projets ne rencontrent pas leurs difficultés au stade du prototype, mais après la décision de poursuivre. Nous examinons donc, lorsque cela est déterminant, qui utilisera réellement le système, quels rôles changent, qui contrôle les résultats, qui peut corriger ou interrompre le fonctionnement, quelles compétences doivent être disponibles, quels indicateurs permettront de vérifier la valeur produite, comment les erreurs et exceptions seront traitées, quelles dépendances nouvelles seront créées, quelles conditions doivent être réunies avant généralisation.

Un contrôle humain écrit dans un document ne suffit pas. Il doit correspondre à un fonctionnement réel : une personne identifiée, disposant des informations, de la compétence, de l'autorité et du temps nécessaires pour intervenir.

Ce que le croisement permet de voir

L'intérêt de la revue n'est pas de produire quatre diagnostics. Il est de faire apparaître des conséquences qui restent invisibles lorsque les sujets sont examinés séparément.

• Performance technique × droit — une variable améliore fortement un modèle mais ne peut pas légitimement fonder la décision envisagée ; la performance réellement utilisable n'est donc plus celle annoncée.
• Prototype × organisation — le système fonctionne en démonstration mais aucun rôle, processus ou contrôle n'a été prévu pour l'exploiter dans la durée.
• Prix × architecture × dépendance — une solution peu coûteuse à l'entrée crée un coût de migration ou une dépendance qui modifie son coût réel.
• ROI × coût complet — un gain attendu paraît convaincant tant que la maintenance, les données, la supervision et la sortie ne sont pas intégrées au calcul.

C'est ce type de déplacement qui peut transformer un GO apparent en AJUSTER — ou rendre rationnel un STOP.

Le verdict

L'évaluation aboutit à une conclusion écrite.

GO

Les hypothèses essentielles sont suffisamment étayées. La valeur attendue justifie l'engagement et les principaux risques ou dépendances sont maîtrisables. Le verdict précise les conditions à préserver lors de la suite du projet.

AJUSTER

Le projet présente une valeur potentielle, mais certaines hypothèses doivent être corrigées avant engagement : réduire le périmètre, prolonger une expérimentation, revoir le business case, demander des preuves complémentaires, modifier l'architecture, organiser le contrôle humain, réduire une dépendance, ou négocier certaines conditions avec un prestataire.

STOP

Les éléments examinés ne justifient pas l'engagement dans les conditions proposées. STOP n'est pas un échec de la mission : éviter un investissement dont les hypothèses ne résistent pas à l'examen est précisément l'un des résultats possibles de la revue.

Ce que vous recevez

Sous 5 jours ouvrés après réception des éléments nécessaires :

• la décision reformulée ;
• les principales hypothèses examinées ;
• les points établis et ceux qui restent incertains ;
• les interactions importantes entre technique, droit, économie et organisation ;
• les risques ou dépendances susceptibles de modifier l'arbitrage ;
• les éventuelles conditions à réunir avant engagement ;
• un verdict GO / AJUSTER / STOP argumenté.

Le niveau de détail dépend du projet et du périmètre convenu avant la mission.

Quels documents pouvons-nous examiner ?

Selon l'état du projet : note de cadrage, dossier de financement, business case, résultats de POC, architecture cible, documentation technique, éléments relatifs aux données, proposition ou devis fournisseur, projet de contrat, analyse de risques, supports COMEX ou comité d'investissement, indicateurs de performance. Il n'est pas nécessaire que tous ces éléments existent : leur absence peut elle-même constituer une information importante pour la décision.

Ce que cette évaluation n'est pas

Cette intervention n'est pas un audit technique exhaustif de la solution, une consultation juridique autonome, un audit de conformité générique, une sélection de prestataire, un audit détaillé du contrat, une mission d'intégration, ni une validation automatique du projet.

Si le projet est déjà validé et que la question porte désormais sur le choix du fournisseur, l'intervention pertinente est plutôt l'analyse de proposition prestataire. Si le fournisseur est choisi et que la question porte sur ce que le contrat vous engage réellement à accepter, voir l'audit de contrat IA / SI.

Une preuve de concept n'est qu'une information parmi d'autres

Le passage du POC à la production n'est pas traité comme une offre séparée : c'est une situation particulière de la décision d'investir. Un prototype convaincant peut justifier une industrialisation, une industrialisation sous conditions, une nouvelle expérimentation, une réduction du périmètre, une solution différente, ou l'arrêt. La question n'est pas de « réussir le passage à l'échelle » à tout prix, mais de déterminer si cette trajectoire constitue encore la meilleure décision une fois ses conséquences réellement instruites.