Critères de choix et protocole d'évaluation
La grille pondérée
À pondérer une fois, en comité, avant de regarder les produits — sans quoi la pondération s’ajuste inconsciemment au favori.
| Critère | Question | Poids indicatif |
|---|---|---|
| Couverture des écosystèmes | Couvre-t-il les langages et plateformes que vous utilisez réellement ? | 20 % |
| Fidélité des SBOM produits | Écart mesuré avec un contrôle croisé, sur vos artefacts | 15 % |
| Qualité de la corrélation | Taux de faux positifs mesuré sur un échantillon connu | 15 % |
| Prise en charge du VEX et de CSAF | Peut-on documenter et publier les décisions ? | 10 % |
| Archivage long terme | Historique conservé, export intégral possible | 10 % |
| API et automatisation | Tout est-il pilotable sans interface graphique ? | 10 % |
| Souveraineté | Où sont hébergées les données ? Quelles sorties de l’Union ? | 8 % |
| Réversibilité | Peut-on partir avec vos SBOM, votre historique et vos VEX ? | 5 % |
| Besoins juridiques | Attributions, rapports de licences, registre d’exceptions | 5 % |
| Coût total sur cinq ans | Licence, exploitation, intégration, formation | Éliminatoire au-delà du budget |
Les deux critères les plus souvent sous-pondérés sont la réversibilité et le coût d’exploitation. Les deux se paient à la fin.
Le protocole d’évaluation
Une évaluation crédible se mène sur vos artefacts, pas sur la démonstration du fournisseur.
Durée : quatre à six semaines. Périmètre : trois produits représentatifs — un produit simple, un produit multi-langages, un produit embarqué ou conteneurisé.
Étapes
- Constituer un jeu de référence. Pour chaque produit, établir manuellement la liste des composants attendus, au moins pour les dépendances directes et un échantillon de transitives. C’est le travail le plus ingrat, et c’est lui qui rend l’évaluation objective.
- Injecter des cas connus. Ajouter délibérément un composant vulnérable connu, un composant sous licence copyleft, un composant vendorisé, un composant lié statiquement.
- Mesurer, pour chaque candidat :
- composants trouvés / attendus (rappel) ;
- composants signalés à tort (précision) ;
- vulnérabilités réelles détectées et faux positifs ;
- licences correctement identifiées ;
- temps ajouté à la construction ;
- effort d’intégration en jours-personnes.
- Tester la réversibilité. Exporter l’intégralité des données et vérifier que l’export est exploitable sans l’outil.
- Tester la restitution. Simuler une demande d’autorité sur une version ingérée trois semaines plus tôt.
- Noter selon la grille, et documenter.
Ce qui n’est pas une évaluation
- Une démonstration sur les dépôts de démonstration du fournisseur.
- Une comparaison de listes de fonctionnalités.
- Un essai gratuit sur un seul projet simple.
- Un avis d’analyste sans mesure sur vos artefacts.
La recommandation d’architecture
- Un générateur ouvert et standardisé comme source primaire, pour que les SBOM restent portables. Un SBOM enfermé dans un format propriétaire est une dette.
- Une plateforme de pilotage auto-hébergeable pour démarrer, afin de valider les processus, de mesurer les vrais volumes et de disposer d’une base de comparaison factuelle.
- Une décision d’investissement ensuite, fondée sur des écarts mesurés et non sur des promesses : atteignabilité, détection par empreinte, profondeur du volet licences, intégration.
- Le coffre de preuves reste interne, quel que soit l’outil. La plateforme est un outil de travail ; la mémoire probante de l’entreprise ne doit pas dépendre d’un contrat.
Les trois questions à poser à tout fournisseur
- Que se passe-t-il si vous partez ? Format de l’export, exhaustivité, historique et VEX compris, délai de mise à disposition.
- Où sont les données, et qui y accède ? Localisation, sous-traitants, conditions d’accès du support.
- Comment mesurez-vous vos faux positifs ? Une réponse évasive à cette question est en soi une information.