Recherche et découverte · Étape 01 · Notre méthode
Chaque mission OpenQCore commence par une investigation structurée. Avant de proposer de l'intelligence artificielle, de l'automatisation, des logiciels ou de l'infrastructure, nous étudions le problème comme un système : ses objectifs, parties prenantes, flux de travail, décisions, données, technologies, dépendances, contraintes, risques et résultats mesurables.
Notre processus de découverte combine recherche, pensée systémique, analyse d'ingénierie et raisonnement métier pour passer d'un défi observé à une définition du problème défendable.
Parce que la première question ne devrait pas être :
Pas cette question
"Quelle technologie devons-nous déployer ?"
Cette question, plutôt
"Quel problème résolvons-nous réellement — quelles preuves l'appuient, quelles en sont les causes, et quel résultat doit changer ?"
Recherche · Preuves · Analyse des systèmes · Analyse commerciale · Mesure
Pourquoi la découverte passe en premier
L'intelligence artificielle est devenue beaucoup plus facile à expérimenter. Transformer l'expérimentation en valeur organisationnelle mesurable reste beaucoup plus difficile.
74%
n'avaient pas encore démontré ni mis à l'échelle une valeur tangible issue de l'IA.
BCG, Where's the Value in AI?, 2024 · n=1 000 cadres supérieurs.
La recherche de BCG de 2024, basée sur 1 000 CxO et cadres supérieurs couvrant plus de 20 secteurs et 59 pays, a révélé que seules 26 % des entreprises avaient développé les capacités nécessaires pour dépasser les preuves de concept et générer une valeur tangible grâce à l'IA.
Cela ne signifie pas que la technologie est inefficace. Cela signifie que la technologie seule est insuffisante.
Les organisations peuvent commencer par un modèle, une plateforme ou une technologie d'automatisation et ne découvrir que plus tard que la contrainte sous-jacente se situe ailleurs : processus fragmentés, données inaccessibles, responsabilités peu claires, limitations d'intégration, contrôles inadéquats, objectifs mal définis ou un problème qui n'a jamais été mesuré en premier lieu.
OpenQCore inverse donc la séquence : la technologie doit être choisie comme conséquence de la compréhension du problème — et non comme substitut à cette compréhension.
Une approche multidisciplinaire
Les problèmes organisationnels complexes appartiennent rarement à une seule discipline. OpenQCore les étudie selon trois perspectives complémentaires.
Observer · Questionner · Émettre une hypothèse · Tester · Valider
Le raisonnement scientifique nous aide à distinguer les observations des suppositions, à formuler des questions, à examiner des explications concurrentes et à déterminer quelles preuves soutiendraient ou contrediraient une hypothèse. Nous ne supposons pas que la première explication soit la bonne.
Systèmes · Interfaces · Données · Dépendances · Contraintes · Fiabilité
L'analyse d'ingénierie examine comment les composants interagissent au sein du système global — logiciels, infrastructure, données, personnes, processus, interfaces, systèmes externes et dépendances opérationnelles.
Cette perspective est conforme à la pensée moderne en ingénierie des systèmes. ISO/IEC/IEEE 15288:2023 définit les processus du cycle de vie des systèmes applicables aux éléments individuels d'un système et aux systèmes de systèmes, avec la participation des parties prenantes tout au long du cycle de vie.
Objectifs · Économie · Processus · Risque · Valeur · Mesure
L'analyse métier détermine pourquoi le problème est important. Nous examinons le résultat souhaité, les parties prenantes concernées, l'impact opérationnel, les considérations économiques, les contraintes organisationnelles et la manière dont l'amélioration serait mesurée.
La transformation par l'IA est souvent abordée principalement en termes de modèles et d'algorithmes. Les preuves issues des mises en œuvre suggèrent un tableau plus large : la recherche de BCG de 2024 indiquait qu'environ 70 % des défis rencontrés par les entreprises dans les initiatives d'IA concernaient les personnes et les processus, environ 20 % la technologie, et seulement 10 % les algorithmes.
10%
Algorithmes
Étude mondiale BCG « Build for the Future 2024 » · n = 1 000.
20%
Technologie & données
Étude mondiale BCG « Build for the Future 2024 » · n = 1 000.
70%
Personnes & processus
Étude mondiale BCG « Build for the Future 2024 » · n = 1 000.
Ces pourcentages sont le cadre de recherche de BCG, pas une loi universelle. Mais ils renforcent un principe d'ingénierie important : le modèle n'est qu'un composant d'un système sociotechnique plus vaste. Pour OpenQCore, la phase de découverte examine donc non seulement la couche d'intelligence, mais aussi l'environnement opérationnel dans lequel cette intelligence serait introduite.
La méthodologie de recherche OpenQCore
La phase de découverte est menée comme une séquence structurée d'investigation. La profondeur exacte varie selon l'engagement, mais la structure analytique reste constante.
Quel résultat importe — et pour qui ?
Nous commençons par identifier les personnes, fonctions et systèmes affectés par le problème. La demande exprimée par une organisation n'est pas automatiquement considérée comme l'objectif sous-jacent — "nous avons besoin d'un agent IA" décrit une possible mise en œuvre, et non encore le problème métier ou d'ingénierie.
Nous examinons
Parties prenantes · Propriétaires de décision · Utilisateurs · Objectifs métier · Objectifs opérationnels · Incitations · Dépendances · Exigences conflictuelles
Résultat
Modèle des parties prenantes et des objectifs
Comment le système fonctionne-t-il réellement aujourd'hui ?
Nous reconstruisons le processus opérationnel actuel plutôt que de nous fier uniquement à la façon dont il est documenté. Le cas échéant, nous établissons des repères quantitatifs pour le flux de travail existant.
L'analyse peut inclure
Processus · Tâches · Décisions · Transferts · Files d'attente · Exceptions · Intervention humaine · Goulots d'étranglement · Retouches · Flux d'information
Résultat
Modèle opérationnel de l'état actuel
Dans quel environnement technique travaillons-nous ?
Nous examinons l'architecture entourant le problème et étudions séparément l'environnement des données. Cela importe car une capacité d'IA qui fonctionne en expérimentation peut néanmoins être inadaptée à la production si les informations requises ne peuvent pas être accessibles de façon fiable, sécurisée et avec une qualité suffisante.
Nous examinons
Applications · Services · API · Bases de données · Infrastructure · Intégrations · Identité · Sécurité · Dépendances externes — ainsi que la disponibilité, l'accessibilité, la structure, la qualité, la traçabilité, la propriété, la couverture, la fraîcheur et la sensibilité des données
Résultat
Panorama des systèmes et des données
Quel environnement externe influence le problème ?
Une solution techniquement valide peut néanmoins être inappropriée du point de vue opérationnel ou commercial. L'étendue dépend de la mission — un système de santé réglementé, une plateforme financière et un outil de productivité interne n'exigent pas les mêmes formes d'investigation contextuelle.
Le cas échéant, nous examinons
Conditions du marché · Structure du secteur · Réglementation · Normes techniques · Environnement concurrentiel · Paysage technologique · Attentes des clients · Dépendances externes
Résultat
Modèle du contexte et de l'environnement externe
Qu'est-ce qui limite l'espace des solutions ?
Les contraintes sont traitées comme des entrées de conception plutôt que comme des surprises découvertes lors de la mise en œuvre. Nous séparons également explicitement les faits connus, les hypothèses, les inconnues connues, les dépendances et les risques — parce que l'incertitude doit être documentée, et non convertie silencieusement en certitude.
Nous identifions les
Contraintes techniques, opérationnelles, budgétaires et temporelles · Exigences en matière de sécurité, de confidentialité et de réglementation · Contraintes organisationnelles · Risques d'adoption · Dépendances d'intégration · Limitations liées aux données
Résultat
Registre des contraintes, des hypothèses et des risques
Qu'est-ce qui doit changer exactement ?
La découverte aboutit à une définition précise du problème, couvrant l'état observé, les preuves, les causes profondes, le système affecté, la ligne de base, l'état cible, les critères de succès, les contraintes et les non-objectifs explicites.
La définition comprend
État observé · Preuves · Causes profondes · Système affecté · Ligne de base · État cible · Critères de réussite · Contraintes · Non-objectifs
Résultat
Définition du problème validée
Le cycle de découverte
La découverte n'est pas simplement une liste de contrôle remplie une fois, de gauche à droite.
Observer
Analyser
Cartographier
Formuler une hypothèse
Valider
Définir
Une fois qu'un degré de confiance suffisant a été établi : problème validé → stratégie & architecture.
Application de la méthodologie
Un problème observé et sa cause sous-jacente ne sont pas nécessairement la même chose. Considérez un exemple opérationnel simplifié.
Condition observée: Le traitement des demandes clients prend 48 heures.
Preuves du flux de travail: Les demandes passent par plusieurs approbations manuelles.
Preuves système: Les informations pertinentes sont réparties entre des applications déconnectées.
Preuves des données: Les mêmes informations sont récupérées et vérifiées à plusieurs reprises.
Hypothèse de la cause profonde: Un flux de travail fragmenté et des informations inaccessibles entraînent un travail humain répété.
À ce stade, l'ajout d'une interface conversationnelle peut améliorer l'expérience client sans résoudre la contrainte de traitement sous-jacente. La question d'ingénierie change donc de « Comment ajoutons-nous de l'IA ? » à « Quelle intervention modifie le mécanisme causal produisant le résultat indésirable ? » — cette distinction est au cœur de la recherche et de la découverte.
Observation : La vérification manuelle des documents est associée à un goulot d'étranglement significatif dans le traitement.
Hypothèse : Un flux de travail d'intelligence documentaire contrôlé peut réduire la relecture manuelle tout en maintenant les contrôles de vérification requis.
Preuves requises : Documents représentatifs · Taux d'erreur existants · Schémas d'exception · Exigences d'examen · Temps de traitement
Évaluation : Qualité d'extraction · Taux d'exception · Taux de relecture humaine · Temps de traitement · Modes de défaillance
Décision : Soutenir · Modifier · Rejeter l'hypothèse
L'objectif n'est pas de prouver qu'une technologie proposée fonctionne. L'objectif est de déterminer si les preuves justifient son utilisation.
Définir la réussite avant la mise en œuvre
Si le succès n'est défini qu'après la mise en œuvre, presque n'importe quel résultat peut être interprété comme un succès. OpenQCore établit donc des références pertinentes et des critères d'évaluation pendant la phase de découverte.
Durée du cycle
Combien de temps dure le processus ?
Coût par opération
Quelles ressources chaque transaction consomme-t-elle ?
Taux d'erreur
À quelle fréquence le processus produit-il un résultat incorrect ?
Débit
Quelle quantité de travail le système peut-il traiter ?
Effort humain
Quelle intervention manuelle est nécessaire ?
Fiabilité
Dans quelle mesure le système fonctionne-t-il de manière constante ?
Qualité des décisions
Avec quelle précision ou quelle constance les décisions sont-elles prises ?
Taux d'automatisation
Quelles opérations peuvent être réalisées sans intervention manuelle ?
Exposition au risque
Quels risques opérationnels, de sécurité ou de conformité existent ?
Indicateurs d'expérience
Comment le processus affecte-t-il les clients, les employés ou d'autres utilisateurs ?
La structure est simple : Situation initiale → Intervention → Objectif → Mesure → Évaluation.
Si le changement désiré ne peut pas être décrit, le succès de la solution ne peut pas être évalué de manière significative.
L'IA nécessite une analyse des risques contextuelle
Pour les engagements liés à l'IA, la phase de découverte examine également si l'utilisation proposée de l'IA est appropriée au contexte dans lequel elle opérera. Le cadre de gestion des risques liés à l'IA du NIST organise les activités de gestion des risques autour de quatre fonctions et décrit spécifiquement la gestion des risques comme étant continue tout au long du cycle de vie de l'IA, plutôt qu'un exercice ponctuel de conformité.
Le cadre identifie également des caractéristiques associées à une IA digne de confiance, notamment la validité et la fiabilité, la sécurité, la sûreté et la résilience, la responsabilité et la transparence, l'explicabilité et l'interprétabilité, le renforcement de la confidentialité, et la gestion des biais nuisibles.
Utilisation prévue
Modes de défaillance potentiels
Supervision humaine
Sensibilité des données
Conséquences des décisions
Sécurité
Fiabilité
Exigences d'évaluation
Contrôles opérationnels
Exigences de gouvernance
Cela ne signifie pas que chaque projet nécessite la même architecture de gouvernance. Les contrôles de risque doivent être proportionnés au système, à son contexte et aux conséquences d'une défaillance.
Preuves avant recommandation
Nous recherchons l'intervention que soutiennent les preuves. Des éléments récents confirment l'importance de repenser le travail plutôt que de simplement superposer l'IA aux processus existants.
~2/3
d'organisations n'avaient pas encore commencé à déployer l'IA à l'échelle de l'entreprise.
McKinsey, The State of AI : Global Survey 2025.
39%
ont signalé un impact sur l'EBIT lié à l'IA au niveau de l'entreprise.
McKinsey, The State of AI : Global Survey 2025.
La même recherche identifie la refonte des flux de travail comme une caractéristique clé des organisations obtenant une plus grande valeur de l'IA — une des raisons pour lesquelles OpenQCore étudie le modèle opérationnel entourant la technologie plutôt que de considérer le déploiement lui-même comme l'objectif.
OpenQCore ne commence pas la découverte avec une solution technique prédéterminée. Les preuves peuvent indiquer que l'intervention appropriée est la refonte des processus, l'intégration des systèmes, l'ingénierie logicielle conventionnelle, l'architecture des données, l'automatisation des flux de travail, l'analytique, l'intelligence artificielle, ou une combinaison de celles-ci. Dans certains cas, les preuves peuvent indiquer que la création d'une nouvelle technologie n'est pas justifiée du tout.
OpenQCore ne recommande pas l'intelligence artificielle parce que c'est à la mode. Nous la recommandons lorsque le problème, les éléments de preuve, l'économie et les contraintes opérationnelles justifient son utilisation — et nous précisons clairement quand ce n'est pas le cas.
Problème → Preuves → Exigences → Contraintes → Interventions candidates → Évaluation → Approche la mieux adaptée — pas : IA → Trouver un endroit pour l'utiliser.
Le choix de la technologie découle de l'investigation.
Les hypothèses sont identifiées plutôt que présentées comme des faits.
Les conclusions importantes doivent être reliées aux preuves qui les étayent.
Lorsque l'incertitude existe, des explications concurrentes doivent être envisagées.
Les critères de succès sont définis avant la mise en œuvre lorsque cela est praticable.
Les inconnues et les limites restent visibles.
Le niveau d'analyse doit refléter le coût, la complexité et le risque de la décision.
Ce que produit la découverte
La recherche et la découverte n'ont pas vocation à se terminer par une présentation pleine d'observations. Elles doivent produire des artefacts qui peuvent éclairer une décision d'ingénierie. Selon l'étendue de l'engagement, ceux-ci peuvent inclure :
Le contexte du problème, les preuves, les observations et les principales conclusions.
Qui est affecté, qui prend les décisions et quels résultats importent.
Comment le travail et l'information circulent aujourd'hui dans l'organisation.
Applications, interfaces, sources de données, dépendances et contraintes techniques.
Explications étayées par des preuves pour l'état observé.
Performance actuelle par rapport aux indicateurs opérationnels ou techniques pertinents.
Exigences fonctionnelles, techniques, opérationnelles et de gouvernance identifiées lors de la phase de découverte.
Faisabilité technique, des données, d'intégration et opérationnelle, lorsque nécessaire.
Interventions potentielles priorisées en fonction des preuves, de la valeur, de la faisabilité et des risques.
Limitations connues, hypothèses, dépendances et risques importants.
Objectifs, indicateurs et approche d'évaluation.
La porte de décision de la découverte
Le but de la découverte n'est pas de garantir qu'un projet se poursuive. Il est de déterminer s'il doit l'être. Un engagement de découverte peut donc se conclure par l'une des orientations suivantes :
Le problème est suffisamment défini, les preuves soutiennent l'intervention et une approche d'ingénierie semble réalisable.
Des incertitudes importantes subsistent et des preuves supplémentaires sont nécessaires.
Le problème initial ou l'intervention proposée ne correspond pas à ce que l'enquête a révélé.
L'objectif reste valide, mais une intervention technique ou opérationnelle différente est plus appropriée.
La valeur attendue, la faisabilité ou le risque ne justifient pas la mise en œuvre.
Ne pas construire le mauvais système peut être aussi précieux que de construire le bon.
De la recherche à l'architecture
Recherche & Découverte n'existe pas séparément du cycle de vie de l'ingénierie. Ses résultats deviennent des entrées pour l'étape suivante : Preuves → Définition du problème validée → Exigences → Contraintes & Risques → Critères de réussite → Stratégie & Architecture.
L'architecture ne doit pas commencer comme une collection de technologies préférées. Elle doit émerger d'une compréhension défendable de ce que le système doit accomplir, dans quelles contraintes, pour quels parties prenantes, à quel niveau de risque acceptable, et par rapport à quels résultats mesurables.
Étape 02
Transformez un problème validé en une orientation d'ingénierie système.
Vous n'avez pas besoin d'arriver avec une stratégie IA. Apportez le défi opérationnel, la contrainte technique, la question de recherche ou l'objectif commercial. Nous commençons par déterminer ce qui se passe réellement — et ce que les preuves indiquent qu'il convient de faire ensuite.
Références de recherche et méthodologiques
Nous citons ces sources directement plutôt que de les dissimuler, car notre méthodologie s'appuie sur des principes établis issus de l'investigation scientifique, de l'ingénierie des systèmes, de l'ingénierie des exigences, de l'analyse métier et de la gestion des risques.
Boston Consulting Group — Où est la valeur dans l'IA ? (2024)
Basé sur une enquête auprès de 1 000 CxO et cadres supérieurs dans plus de 20 secteurs et 59 pays ; source des chiffres 74 % / 26 % et du principe 10–20–70 mentionnés ci‑dessus.
McKinsey & Company — L'état de l'IA : Enquête mondiale 2025
Source des données sur l'ampleur et l'impact sur l'EBIT au niveau de l'entreprise, ainsi que de la conclusion sur l'importance de la refonte des flux de travail parmi les organisations les plus performantes.
ISO/IEC/IEEE 15288:2023 — Ingénierie des systèmes et des logiciels — Processus du cycle de vie des systèmes
La référence principale en ingénierie pour traiter les systèmes, leurs éléments, leur cycle de vie et leurs parties prenantes de manière structurée.
ISO/IEC/IEEE 29148:2018 — Ingénierie des exigences
Spécifie les processus et les éléments d'information pour l'ingénierie des exigences tout au long des cycles de vie des systèmes et des logiciels ; l'ISO a confirmé l'édition comme actuelle suite à une revue en 2024.
NIST — Cadre de gestion des risques liés à l'intelligence artificielle (AI RMF 1.0)
Favorise une réflexion contextuelle sur les risques liés à l'IA via Gouverner, Cartographier, Mesurer et Gérer, avec une gestion continue des risques tout au long du cycle de vie de l'IA. L'AI RMF 1.0 du NIST est en révision active, c'est pourquoi nous nommons explicitement la version plutôt que d'impliquer qu'il s'agit toujours de la dernière version finale.
