Ce que la préparation doit produire
Pas un score de maturité
Le résultat recherché est une liste de changements réalisables, ordonnés selon les dépendances, les risques et leur contribution aux usages envisagés.
La préparation part de cas d’usage métiers précis — pas d’un achat d’infrastructure, pas de la généralisation d’un prototype. Un diagnostic qui se conclut par une note sur vingt n’a produit aucune décision.
Dix chantiers
| Chantier | Preuves attendues |
|---|---|
| 01 | Stratégie et cas d’usage — fiches de cas, objectifs, indicateurs de valeur, et les décisions qui restent humaines |
| 02 | Cartographie du système — état des lieux, inventaire, registre des dépendances |
| 03 | Données et connaissances — catalogue des sources, matrice des droits, règles de qualité |
| 04 | Interopérabilité — inventaire des interfaces, tests, contrats d’échange |
| 05 | Identités et autorisations — matrice d’habilitation, tests d’accès autorisé et refusé |
| 06 | Sécurité et gouvernance — registre de risques, responsabilités, matrice contrôles-preuves |
| 07 | Infrastructure et hébergement — scénarios, capacité, plan de réversibilité |
| 08 | Plateforme et industrialisation — architecture cible, catalogue des services mutualisables |
| 09 | Fiabilité et exploitation — objectifs de service, tableaux de bord, procédures, tests de restauration |
| 10 | Économie et compétences — dossier d’affaires, plan de compétences, feuille de route |
Sept questions de diagnostic
Elles suffisent à situer une organisation. Une seule sans réponse claire suffit à expliquer l’échec d’un projet d’intelligence artificielle.
- 01Quel problème métier sera résolu, pour quel utilisateur, avec quelle mesure de succès ?
- 02Quelles données sont nécessaires, qui en est responsable et qui peut les consulter ?
- 03Les applications exposent-elles des interfaces documentées et contrôlées ?
- 04Une action suggérée par l’IA peut-elle être vérifiée ou approuvée avant exécution ?
- 05Qui assure l’exploitation, la réponse aux incidents et la restauration ?
- 06Quelles dépendances techniques, contractuelles et humaines doivent pouvoir être remplacées ?
- 07Quel est le coût complet du service, et à quelles conditions son extension est-elle justifiée ?
Un cas concret : l’assistant documentaire interne
Le même projet, selon que le système d’information a été préparé ou non.
| Système non préparé | Système préparé |
|---|---|
| Documents dispersés et parfois obsolètes | Sources inventoriées, responsables désignés, synchronisation définie |
| Droits d’accès peu clairs | Permissions appliquées au moment de la recherche documentaire |
| Réponses difficiles à vérifier | Références aux documents sources et évaluation des réponses |
| Absence de suivi opérationnel | Mesure des erreurs, des latences et des incidents |
| Prototype dépendant d’une personne | Service documenté, maintenable et transférable |
L’enjeu réel. Préparer un service d’information fiable et contrôlé. Le modèle n’en est qu’un composant — et la dernière ligne du tableau rejoint la haute disponibilité humaine : un prototype qui dépend d’une seule personne n’est pas un service.
L’architecture cible
| Couche | Ce qu’elle porte |
|---|---|
| Utilisateurs et applications métiers | Portails, gestion de la relation client, gestion intégrée, gestion documentaire, applications internes |
| Accès et intégration | Identités, passerelle d’interfaces, connecteurs, événements |
| Services d’intelligence artificielle | Recherche augmentée, orchestration, modèles, évaluation, approbations |
| Données et connaissances | Sources, catalogue, qualité, index |
| Plateforme et calcul | Cloud, orchestration, processeurs, stockage |
| Contrôles transverses | Sécurité, gouvernance, observabilité, maîtrise des coûts, continuité |
Vision d’ensemble à adapter au contexte de chaque organisation, non architecture universelle.
Quatre missions
| Mission | Durée indicative | Livrables |
|---|---|---|
| Diagnostic de préparation | 3 à 4 semaines | Cartographie initiale, registre des écarts, plan d’actions priorisé |
| Schéma directeur d’architecture | 4 à 6 semaines | Architectures existante et cible, décisions techniques, modèle opérationnel, feuille de route |
| Mise en place des fondations | 8 à 16 semaines | Composants opérationnels, tests, documentation, transfert de compétences, critères de réception |
| Accompagnement de la gouvernance | Mission récurrente | Décisions d’architecture, tableaux de suivi, revues de risques, rapports périodiques |
Sur les durées et les prix. Les durées sont des hypothèses de conception, non des engagements universels. Les prix se construisent à partir du coût réel, des responsabilités assumées et des budgets effectivement constatés — ils ne figurent pas sur cette page.
La méthode de mission
La troisième étape est celle que les missions de conseil escamotent le plus souvent : vérifier réellement une interface, la qualité d’une source, des permissions ou la faisabilité d’un hébergement — et documenter les incertitudes qui subsistent.
Une feuille de route sur douze mois
| Période | Objet | Résultat |
|---|---|---|
| Mois 1 – 2 | Diagnostic et sélection des cas d’usage | Exigences et risques validés |
| Mois 3 – 4 | Accès aux données, interfaces et identités | Flux et permissions testés |
| Mois 5 – 6 | Premier service en environnement contrôlé | Résultats fonctionnels et sécurité évalués |
| Mois 7 – 9 | Industrialisation et exploitation | Support, observabilité et reprise testés |
| Mois 10 – 12 | Extension à d’autres équipes | Valeur et capacité mesurées |
La première mission à commercialiser est un diagnostic sur périmètre limité, avec cas d’usage identifiés, livrables précis et preuves techniques — plutôt qu’une promesse générale de transformation de toute l’entreprise.
Six limites, dont une technique
Les permissions s’appliquent par les systèmes, pas par une instruction au modèle. Demander à un assistant de ne pas divulguer certains documents ne remplace pas un contrôle d’accès exercé par le système d’information et la couche d’intégration. C’est l’erreur d’architecture la plus fréquente, et la plus lourde de conséquences.
Conformité. Un diagnostic technique ne vaut ni avis juridique ni certification réglementaire ; les obligations dépendent du pays, du secteur et des traitements concernés.
Open source. Vérifier séparément les licences des logiciels et des modèles : des poids accessibles ne signifient pas qu’un modèle est open source.
Données. Utiliser des données fictives ou dûment autorisées pour les démonstrateurs ; ne pas copier de données sensibles dans un outil d’intelligence artificielle sans cadre approuvé.
Économie et compétences. Ne pas présenter durées, économies ou gains comme garantis : les mesurer sur les usages réels. Et une attestation interne ne remplace ni les références clients, ni l’expérience sectorielle, ni les qualifications requises par une mission.
La mission plus large
Préparer un système d’information à l’intelligence artificielle est un cas particulier de la transformation d’entreprise par l’open source, qui couvre sept domaines — de la stratégie à la gouvernance — en cinq étapes.
Le laboratoire qui forme aux mêmes sujets
Le laboratoire Open Source IA enseigne les six niveaux qui permettent de conduire ces missions : recherche augmentée, orchestration, plateforme de modèles, sécurité, gouvernance.
L’auteur
Lionel Sakiti
Program Manager Cloud & IA souveraines. Il travaille sur les infrastructures de paiement, les programmes de cloud et d’intelligence artificielle souverains et la gouvernance des données dans la zone UEMOA.