Le processus
Aucune technologie n’est optimale pour tous les usages. Le meilleur choix dépend du contexte, et il se démontre.
Ce qu’il faut formaliser avant toute présélection
Un besoin correctement écrit élimine déjà la moitié des candidats — par exemple : exploiter quatre-vingts applications, déployer plusieurs fois par jour, isoler les environnements, tenir deux centres de données et restaurer rapidement les services critiques.
- 01Fonctions attendues et cas d’usage
- 02Disponibilité cible, objectifs de reprise et de perte de données
- 03Charge, latence, volumétrie et croissance
- 04Sécurité, confidentialité et conformité applicables
- 05Interopérabilité, interfaces, formats et standards
- 06Réversibilité et portabilité des données
- 07Compétences, support, budget et horizon d’exploitation
La matrice multicritère
Les pondérations ci-dessous sont un exemple pédagogique, pas un barème normatif : elles doivent être validées projet par projet.
| Critère et poids indicatif | La question de décision |
|---|---|
| Adéquation fonctionnelle — 20 % | Couvre-t-elle les besoins prioritaires ? |
| Maturité et références — 15 % | Les preuves sont-elles pertinentes pour notre contexte ? |
| Sécurité — 15 % | Vulnérabilités, correctifs, dépendances et chaîne de livraison sont-ils maîtrisables ? |
| Communauté et gouvernance — 10 % | La maintenance et la gouvernance sont-elles durables ? |
| Exploitabilité — 10 % | Supervision, sauvegarde, restauration, haute disponibilité et mises à jour sont-elles maîtrisables ? |
| Interopérabilité — 10 % | Interfaces, protocoles, standards et formats conviennent-ils ? |
| Compétences — 5 % | Peut-on former, recruter et assurer la relève ? |
| Support — 5 % | Existe-t-il des voies de support adaptées à la criticité ? |
| Coût total de possession — 5 % | Quel coût complet sur l’horizon retenu ? |
| Dépendance et réversibilité — 5 % | Peut-on changer de fournisseur, d’intégrateur ou de solution ? |
La règle qui protège la méthode : une note globale ne compense jamais un critère éliminatoire. Définir une échelle de notation commune, documenter les preuves, et tester la sensibilité du classement aux pondérations — si le vainqueur change quand on déplace un poids de cinq points, la décision n’est pas encore prise.
Les critères éliminatoires
À adapter à la criticité du service. Un seul suffit à écarter un candidat, quel que soit son score.
- ·Licence incompatible avec l’usage, la distribution ou les obligations de l’entreprise
- ·Incapacité démontrée à respecter une exigence réglementaire applicable
- ·Absence de trajectoire crédible de maintenance et de correctifs
- ·Risque de sécurité inacceptable sans mesure compensatoire
- ·Impossibilité de sauvegarder et restaurer les données critiques conformément aux objectifs
- ·Absence de compétences et impossibilité réaliste de les acquérir ou de les contractualiser
Une nuance à conserver. Un projet peu actif n’est pas automatiquement abandonné : il faut examiner son rythme de développement, ses besoins réels de maintenance et les garanties dont il dispose. Un composant stable et peu modifié n’est pas un composant mort.
Évaluer la maturité
Sept dimensions à examiner conjointement : code, communauté, gouvernance, sécurité, versions, adoption, écosystème.
- ·Qualité et disponibilité de la documentation
- ·Fréquence et politique de publication des versions
- ·Durée de support et stratégie de mise à niveau
- ·Diversité des mainteneurs et des organisations contributrices
- ·Traitement des incidents et des vulnérabilités
- ·Compatibilité et stabilité des interfaces
- ·Références d’usage comparables, vérifiables et datées
- ·Existence d’intégrateurs et de prestations de support
Ce qui ne constitue pas une preuve. Le nombre d’étoiles sur un dépôt, le volume de téléchargements ou l’appartenance à une fondation sont des indices. Jamais des preuves suffisantes d’adéquation à une entreprise. La maturité n’est pas la popularité : c’est la capacité à durer.
Le coût total, sur un horizon identique
Dix postes, comparés sur la même durée — cinq ans par exemple — avec les hypothèses et les incertitudes explicitées.
Une licence sans frais ne signifie pas une exploitation sans coûts.
Le protocole de preuve
Ne pas conclure après une simple installation. Dix étapes reproductibles, appliquées à chaque candidat répondant au même besoin.
- 01Installer et configurer selon des procédures documentées
- 02Mesurer les performances sous une charge représentative
- 03Provoquer la panne d’un composant et éprouver la reprise
- 04Sauvegarder et restaurer, avec vérification des données
- 05Éprouver réplication et haute disponibilité si requises
- 06Tester mise à niveau et retour arrière
- 07Vérifier journalisation, métriques, alertes et diagnostic
- 08Vérifier durcissement, accès et gestion des vulnérabilités
- 09Automatiser déploiement et configuration
- 10Mesurer effort humain, délais, incidents et coûts observés
Preuves attendues : protocole, scripts, jeux de données, résultats bruts, écarts aux objectifs, limites, journal d’incidents et recommandation argumentée.
Le test d’exploitabilité
La décision
Elle prend la forme d’un enregistrement de décision d’architecture : contexte, options examinées, critères, preuves, choix retenu, compromis acceptés, risques résiduels, responsables et date de réexamen.
Les livrables attendus
- ·Fiche de besoin et exigences mesurables
- ·Liste des candidats et justification de la présélection
- ·Matrice multicritère et critères éliminatoires
- ·Dossier de maturité, sécurité et gouvernance
- ·Estimation du coût total et hypothèses
- ·Protocole et résultats de la preuve
- ·Procédures d’exploitation, résultats de restauration et de mise à niveau
- ·Décision signée et fiche au radar technologique
Le radar interne
Chaque promotion alimente un radar technologique, avec quatre statuts : à examiner, à tester dans un contexte délimité, approuvée pour des usages explicitement définis, adoptions suspendues en attente de réévaluation.
Ces statuts sont internes. Ils ne constituent ni des certifications externes, ni des jugements universels sur les produits. Chaque fiche précise le périmètre d’usage, les preuves, les compétences requises, les risques, les conditions de support et la date de révision.
Le radar de l’OPPL applique le même principe au domaine des paiements, et la cartographie de l’open source recense les organisations qui gouvernent les projets à évaluer.
La mission type
Ce qu’on ne demande plus à un apprenant
« Installez Keycloak. »
À la place : l’entreprise a besoin d’une gestion des identités et des accès. Définissez les exigences, identifiez les solutions candidates, évaluez leur maturité et leur sécurité, construisez les preuves, comparez leur coût et leur exploitabilité, puis défendez une décision documentée devant le comité d’architecture.
Le terrain d’application
Cette méthode s’exerce dans l’Open Source Enterprise Lab, où les apprenants construisent le système d’information complet d’une entreprise.
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.