En bref
La plupart des achats de murs d'images se décident sur une démonstration. Un fournisseur montre un mur soigné, le comité est impressionné, le contrat est signé — et la réalité opérationnelle dix-huit mois plus tard est un produit différent de ce que la démonstration laissait entendre. Voici un playbook pour mener un bake-off qui prédit le résultat en production plutôt que le résultat de la démonstration : comment construire la présélection, structurer l'évaluation, pondérer les critères, et éviter les erreurs qui ruinent les achats.
Avant le bake-off — le document d'exigences
Un bake-off sans document d'exigences écrit est un concours de beauté. Avant tout contact avec un fournisseur, documentez quatre éléments :
- Le cadre de conformité. Quelles exigences réglementaires s'appliquent — voir la carte de conformité. C'est le premier filtre ; il décide du vivier de fournisseurs avant toute évaluation technique.
- L'inventaire des sources. Chaque flux que le mur doit porter aujourd'hui et le nombre projeté à l'année trois. Type, résolution, transport.
- Le modèle opérateur. Combien de postes opérateurs, à quoi ressemble le flux de travail, si le contrôle multi-opérateurs est nécessaire.
- L'enveloppe budgétaire à cinq ans. Renouvellement et support compris, pas seulement l'achat de l'année zéro. Voir le détail du TCO pour le modèle.
Construire la présélection
Appliquez d'abord le filtre de conformité — il est binaire et écarte les fournisseurs vite. Une exigence de registre Минцифры écarte tout fournisseur non russe. Une exigence FedRAMP s'applique aux services délivrés depuis le cloud : elle écarte donc les fournisseurs de solutions gérées dans le cloud dépourvus de l'autorisation, tandis qu'un logiciel installé sur site sort de son périmètre. Ce qui reste constitue le vivier éligible.
Dans le vivier éligible, présélectionnez trois à cinq fournisseurs couvrant l'éventail architectural — au moins une option à contrôleur matériel et au moins une option logicielle, à moins que le document d'exigences n'en exclue déjà une. Le comparatif des huit plateformes et les pages /vs/ individuelles sont la référence de départ pour savoir qui convient où. Une présélection de plus de cinq est ingérable ; moins de trois risque de manquer la bonne architecture.
Les six critères pondérés
Notez chaque fournisseur présélectionné sur six critères, pondérés selon la fréquence à laquelle chacun décide du résultat en production :
- Adéquation opérationnelle — 35 %. Le logiciel correspond-il au flux de travail opérateur réel, au mix de sources et au modèle d'exploitation IT ? Le facteur le plus important à lui seul, et celui que les démonstrations cachent.
- TCO sur 5 ans — 25 %. L'enveloppe complète, renouvellement et support compris, pas le prix affiché.
- Longévité fournisseur et support — 15 %. Historique d'EOL, cadence de correctifs, chemins d'escalade.
- Étendue du mix de sources — 10 %. Prise en charge native de l'inventaire du document d'exigences, plus une marge pour la projection à l'année trois.
- Profondeur de références — 10 %. Déploiements vérifiables dans le secteur, la région et la tranche d'échelle de l'acheteur.
- Flexibilité de l'architecture — 5 %. Posture sur site / cloud / hybride, exposition au verrouillage.
La pondération compte plus que les chiffres exacts. L'essentiel est que « l'interface est jolie » ne figure pas sur la liste — cela n'a jamais décidé d'un résultat en production et domine les démonstrations précisément parce que c'est facile à montrer.
Structurer le bake-off
Trois étapes, dans l'ordre :
- Revue documentaire. Chaque fournisseur présélectionné répond par écrit au document d'exigences. Cela fait apparaître les écarts de conformité et de mix de sources avant que quiconque ne consacre du temps à une démonstration.
- Démonstration structurée. Pas la démonstration standard du fournisseur — la vôtre. Confiez à chaque fournisseur le même scénario construit à partir de votre inventaire de sources réel et de votre flux de travail opérateur, et faites-le-leur exécuter. Un fournisseur qui ne sait montrer que sa démonstration toute faite vous a appris quelque chose.
- Preuve de concept. Pour les un ou deux premiers, une PoC limitée dans le temps sur une infrastructure réelle avec de vraies sources. C'est là que l'adéquation opérationnelle se vérifie — le critère à 35 % ne peut pas être noté à partir d'une démonstration.
Les erreurs d'évaluation qui ruinent les achats
- Noter la démonstration plutôt que le déploiement. Une démonstration tourne sur le matériel du fournisseur avec le contenu du fournisseur. Elle ne prédit presque rien de la production. Exigez la PoC.
- Traiter le « logiciel » comme une catégorie unique. Une pile à licence perpétuelle et une pile à abonnement par écran ont des TCO sur 5 ans radicalement différents, même si les deux sont du « logiciel ». Notez le modèle tarifaire, pas l'étiquette.
- Sauter la question de l'exploitation IT. Le filtre unique qui décide la plupart des bake-offs est ce que l'équipe IT peut réellement maintenir. Un site sans capacité d'exploitation Linux ne devrait pas attribuer une note élevée à une pile logicielle sur l'adéquation opérationnelle, aussi bon que soit le produit.
- Laisser le comité noter des fonctionnalités qu'il ne sait pas pondérer. Une liste de 200 fonctionnalités est du bruit. Notez les six critères ; tout le reste n'est que du détail qui s'y agrège.
- Ignorer la projection à l'année trois. Un mur dimensionné pour le nombre de sources et de postes opérateurs d'aujourd'hui, évalué uniquement par rapport à aujourd'hui, est un achat à refaire dans trois ans.
La matrice de décision
Le résultat du bake-off est une seule matrice : les fournisseurs présélectionnés en lignes, les six critères pondérés en colonnes, une note dans chaque cellule, un total pondéré par fournisseur. La matrice n'est pas la décision — c'est l'entrée structurée de la décision. Si le total pondéré et l'instinct du comité divergent, ce désaccord est le résultat le plus utile de tout le processus : il signifie qu'un critère est mal pondéré, ou que l'instinct réagit à quelque chose qui n'a pas été capturé. Résolvez-le explicitement plutôt que de contourner discrètement la matrice.
Où se place Craft Wall dans un bake-off
Craft Wall obtient de bonnes notes sur les critères du bake-off où son architecture est adaptée — TCO sur 5 ans, étendue du mix de sources, flexibilité de l'architecture, adéquation opérationnelle pour un site disposant d'une capacité d'exploitation Linux. Il obtient des notes plus basses lorsque le document d'exigences réclame une marque Tier 1 avec un horizon de support de 15 à 20 ans, un approvisionnement au registre Минцифры, ou une latence KVM opérateur inférieure à la trame.
Le cadrage honnête pour une équipe d'achat : Craft Wall est conçu pour gagner les bake-offs où l'architecture logicielle est la bonne réponse, et pour perdre proprement ceux où elle ne l'est pas. Les pages de comparatif /vs/ documentent exactement où chaque ligne se situe face à chaque grand concurrent — utilisez-les comme référence par critère lors de la construction de la matrice.
Conclusion
Un bake-off de mur d'images mené sur un document d'exigences, noté sur six critères pondérés et vérifié par une PoC sur infrastructure réelle prédit le résultat en production. Un bake-off mené sur des démonstrations prédit la démonstration. L'effort supplémentaire du processus structuré est minime face au coût de découvrir le mauvais choix dix-huit mois après le début d'un déploiement de cinq ans.
À lire ensuite : le comparatif des huit plateformes pour le point de départ de la présélection, le détail du TCO pour le critère de coût sur 5 ans, et le calculateur de TCO interactif pour noter vos propres chiffres.