Vaporware en production : comment les produits annoncés brisent les systèmes réels

Ce qu’est vraiment le vaporware (et ce que ce n’est pas)

Le vaporware est un produit ou une fonctionnalité annoncée publiquement sans chemin fiable et vérifiable vers la livraison. Parfois il ne voit jamais le jour. Plus souvent, il est livré sous une forme plus restreinte, plus lente, moins intégrée ou moins maintenable que l’annonce le laissait entendre. L’essentiel n’est pas « il est en retard ». L’essentiel est on vous a demandé de prendre des décisions comme si c’était déjà là.

Il y a une différence entre :

• Retards normaux : une fonctionnalité existe en interne, dispose de code fonctionnel et le fournisseur gère la QA/la conformité/la préparation du support.
• Vaporware stratégique : la fonctionnalité est annoncée surtout pour geler un marché, freiner le churn ou contrecarrer le lancement d’un concurrent — sans implémentation capable de tenir l’affirmation.
• Vaporware accidentel : l’ingénierie croyait que c’était faisable, puis la physique, la complexité ou la réalité d’intégration sont arrivées et se sont installées.

Du point de vue SRE, l’étiquette importe moins que le comportement : considérez les fonctionnalités non livrées comme inexistantes. Pas « probablement bientôt ». Pas « en bêta ». Pas « on a vu une démo ». Inexistantes tant que vous ne pouvez pas les exécuter, les observer et les supporter.

Vérité sèche : une démo fournisseur est une performance, pas une mesure. Votre travail est d’en faire une mesure.

Blague #1 (courte, pertinente) : La roadmap est le seul artefact technologique qui devient moins précis quand il devient plus coloré.

Pourquoi le vaporware persiste dans l’informatique d’entreprise

Le vaporware n’est pas « juste le marketing qui fait son marketing ». C’est un équilibre créé par des incitations :

1) Annoncer coûte moins cher que livrer

Un communiqué de presse coûte presque rien. Livrer une fonctionnalité fiable demande du temps d’ingénierie, de la QA, de la documentation, la formation du support, des outils opérationnels et — pire — de la maintenance continue. Si la direction peut obtenir un impact commercial rien qu’avec l’annonce, la tentation est évidente.

2) Les acheteurs achètent souvent des récits, pas des capacités

Les processus d’achat favorisent la comparabilité. Les fournisseurs répondent par des cases à cocher. Les cases à cocher incitent à de grandes promesses. Et soudain « multi-région active-active, zéro RPO » est une ligne à côté de « prend en charge SNMP ». La réalité n’est pas aussi nette.

3) Les équipes techniques sont entraînées dans des pré-engagements

Le moment le plus dangereux est lorsque la direction demande à l’ingénierie : « Peut-on supposer que cela existera d’ici le T3 ? » C’est là que l’architecture devient otage du calendrier d’autrui.

4) Le système immunitaire des entreprises est faible face à l’optimisme

L’optimisme ressemble à de la dynamique. Le scepticisme ressemble à un « blocage ». Dans beaucoup d’organisations, le sceptique avait raison et perd encore — jusqu’à ce que la production le rende public.

5) L’intégration est l’endroit où les promesses meurent

La plupart des affirmations de vaporware ne sont pas impossibles isolément. Elles sont impossibles une fois combinées à tout le reste que le produit fait déjà : chiffrement, snapshots, réplication, quotas, isolation multi-tenant, télémétrie, journaux de conformité et « fonctionne avec notre fournisseur d’identité ».

Faits historiques et contexte utiles

Un peu de contexte aide parce que le vaporware répète des schémas. Voici des points concrets à retenir (pas de la nostalgie, juste de la reconnaissance de motifs) :

1. Le terme « vaporware » s’est répandu au début des années 1980 dans la presse informatique personnelle, quand des fournisseurs pré-annonaient des produits pour bloquer des concurrents.
2. Les pré-annonces sont devenues une arme compétitive quand la distribution et les mises à jour logicielles étaient lentes ; capturer l’esprit du marché tôt était parfois aussi important que livrer.
3. L’ère entreprise des années 1990 a normalisé la vente sur des « futurs » : de gros contrats étaient négociés sur des engagements de roadmap, pas seulement sur les capacités actuelles.
4. Une attention antitrust a parfois rendu les fournisseurs plus prudents autour des pré-annonces, mais sans les éliminer ; la pratique s’est juste formalisée.
5. L’ère du cloud a relancé le vaporware sous une nouvelle forme : « région bientôt disponible », « aperçu de service » et fonctionnalités en liste d’attente utilisées dans des architectures bien avant qu’elles ne soient GA.
6. Les fournisseurs de stockage ont historiquement survendu les ratios de déduplication et de compression, car les charges varient et les benchmarks synthétiques facilitent les mensonges.
7. « Migration sans interruption » est une promesse récurrente depuis des décennies ; les migrations réelles sont contraintes par le comportement des applications, pas seulement par le canal de stockage.
8. Les roadmaps sécurité sont un foyer fréquent de vaporware : « sauvegardes immuables », « récupération air-gapped » et « protection contre les rançongiciels » arrivent souvent incomplètes ou fragiles en production.
9. Les standards ouverts servent parfois de bouclier marketing : « compatible S3 » et « natif Kubernetes » peuvent signifier des niveaux de compatibilité très différents.

Remarquez le thème : le vaporware prospère là où la vérification est difficile. Si vous ne pouvez pas le tester rapidement, vous êtes plus susceptible d’acheter une histoire.

Modes d’échec opérationnel : comment le vaporware casse les systèmes

Mode d’échec A : l’architecture dépend de primitives non livrées

L’erreur la plus coûteuse est de concevoir un système qui exige une fonctionnalité particulière — écritures inter-régions, snapshots consistants, gestion transparente des clés, peu importe — puis de découvrir que le produit réel ne peut pas la faire, ou ne le peut pas sous vos contraintes.

Schéma de diagnostic : le « contournement temporaire » devient permanent et s’enracine : tâches cron, scripts fragiles, étapes manuelles, exceptions dans les audits et basculements Rube Goldberg.

Mode d’échec B : la « bêta » est traitée comme une fonctionnalité supportée

La bêta n’est pas un stade de maturité ; c’est un stade de responsabilité. Les fournisseurs diront souvent « support limité ». En pratique cela signifie : astreinte limitée, urgence de correction faible et documentation écrite à la va-vite.

Mode d’échec C : exigences non fonctionnelles sacrifiées

L’annonce couvre le débit, mais pas l’observabilité. Ou le chiffrement, mais pas la rotation des clés. Ou « immuable », mais pas la conservation légale, la journalisation des accès ou les workflows de récupération. La production exige ces bords ennuyeux.

Mode d’échec D : la dette d’intégration va directement à l’exploitation

Quand un fournisseur dit « s’intègre à votre écosystème », votre écosystème est toujours plus vaste qu’il ne le suppose. Identité, réseau, DNS, proxy, audit, ticketing, sauvegardes, monitoring, répartition des coûts. L’écart devient votre glue code. La glue code devient votre page d’astreinte.

Mode d’échec E : les achats vous verrouillent avant l’arrivée de la réalité

Les engagements pluriannuels basés sur des fonctionnalités futures sont classiques. Quand la fonctionnalité tarde ou déçoit, vous avez déjà migré des données sur la plateforme, formé des équipes et réécrit des runbooks. Le coût du changement devient une cage.

Voici l’axiome opérationnel : si une affirmation produit ne peut pas être validée dans votre environnement avec votre chemin de données, ce n’est pas une capacité — c’est un risque.

Une citation, parce qu’elle survit aux audits et aux réunions budgétaires. L’idée de Kim (Gene) se formule souvent ainsi ; je la paraphrase pour rester honnête :

Idée paraphrasée (Gene Kim) : La fiabilité n’est pas une fonctionnalité que l’on ajoute après coup ; c’est une propriété que l’on conçoit et exploite dans le système dès le départ.

Playbook de diagnostic rapide : trouver le goulot vite

Ce playbook s’applique au moment où « la nouvelle plateforme » est déployée et que quelque chose cloche : pics de latence, effondrement du débit, le basculement ne bascule pas, ou une fonctionnalité promise se comporte comme une rumeur. Vous avez besoin d’une réponse rapide : est-ce l’application, l’hôte, le réseau, le stockage ou le morceau manquant du produit ?

Premier point : confirmer ce qui est réellement déployé

• Vérifiez les versions, modules activés, état de licence et flags de fonctionnalité. La moitié des « incidents vaporware » sont des cas où « ça existe mais pas dans votre SKU/région/build ».
• Vérifiez que vous ne lisez pas la documentation marketing tout en exécutant le firmware du trimestre précédent.

Deuxième point : identifier le symptôme dominant

• Latence (surtout la latence de queue) signifie en général contention, mise en file ou écritures synchrones.
• Plafonds de débit indiquent souvent un point d’étranglement unique : agrégat NIC, un cœur CPU occupé, profondeur de file unique, un nœud passerelle saturé.
• Anomalies de cohérence indiquent généralement des couches de cache ou des sémantiques de réplication plus faibles que prévu.
• Échecs de basculement signifient souvent que la prévention de split-brain fait son travail — au prix de la disponibilité — ou que vos dépendances n’ont pas été incluses.

Troisième point : tester le chemin de données en isolation

• Comparer disque local vs stockage réseau vs gateway objet.
• Mesurer avec des outils qui montrent IOPS, distribution de latence et utilisation CPU.
• Capturer toujours la commande, la sortie et le détail de l’environnement. Sinon vous discutez sur des impressions.

Quatrième point : cartographier la « fonctionnalité promise » au comportement observable

• « Immuable » signifie que vous ne devez pas pouvoir supprimer ou écraser des objets/blocs pendant la période de rétention — même en tant qu’admin.
• « Active-active » signifie deux chemins d’écriture indépendants sans primaire caché.
• « Zéro RPO » signifie que vous pouvez tuer un site en cours d’écriture et que l’écriture est quand même engagée ailleurs avec des sémantiques définies.

Cinquième point : décider vite — corriger, contourner ou revenir en arrière

Si le produit ne peut pas satisfaire une exigence non négociable, ne « optimisez » pas. Revenez en arrière et renégociez. L’optimisation sert les systèmes qui sont fondamentalement corrects. Le vaporware est une incorrection fondamentale en costume.

Tâches pratiques de vérification (avec commandes)

Ce sont des tâches réelles à exécuter pendant la due diligence, un POC ou la réponse à incident. Chaque tâche inclut : commande, ce que signifie la sortie et la décision à prendre. Elles sont centrées Linux parce que la production l’est.

Task 1: Confirm kernel and OS basics (avoid phantom perf bugs)

cr0x@server:~$ uname -a
Linux app01 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Signification de la sortie : La version du noyau impacte NVMe, piles TCP, io_uring et le comportement du système de fichiers. « Le fournisseur a testé sur 5.4 » compte si vous êtes sur 6.5.

Décision : Si votre noyau diffère significativement de la matrice de support déclarée par le fournisseur, alignez les versions pour le POC ou considérez les résultats comme non reproductibles.

Task 2: Verify product version and build (marketing loves ambiguity)

cr0x@server:~$ cat /etc/vendor-storage/version
VendorStorageOS 3.2.1-build.4587

Signification de la sortie : Vous exécutez un build précis ; « 3.2 » dans les slides n’est pas un numéro de build.

Décision : Si la fonctionnalité promise requiert « 3.3+ », suspendre la discussion d’architecture jusqu’à ce que vous puissiez exécuter cette version.

Task 3: Check license or entitlement state (features vanish here)

cr0x@server:~$ vendorctl license show
License: ENTERPRISE
Features:
  replication: enabled
  immutable-snapshots: disabled
  s3-gateway: enabled
  kms-integration: enabled

Signification de la sortie : La fonctionnalité n’est pas « absente », elle est désactivée par la licence. Cela compte toujours comme « non disponible pour vous ».

Décision : Soit vous montez l’entitlement dans le contrat, soit vous redesigniez en supposant que la fonctionnalité n’existe pas.

Task 4: Verify DNS and routing to the supposed “multi-region” endpoints

cr0x@server:~$ dig +short storage-global.example.internal
10.40.12.10

Signification de la sortie : Le « endpoint global » résout en une seule IP. Ce n’est pas global ; c’est un VIP unique déguisé.

Décision : Si la HA repose sur un basculement DNS, exigez des temps de basculement testés et le comportement des caches, ou migrez vers une approche anycast/load-balancer que vous contrôlez.

Task 5: Observe network path and MTU issues (latency masquerading as storage)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens160           UP             00:50:56:aa:bb:cc
ens192           UP             00:50:56:dd:ee:ff

Signification de la sortie : Les interfaces sont up. Cela ne prouve pas que les jumbo frames ou les offloads sont corrects, mais c’est une base.

Décision : Si vous attendiez une NIC dédiée au stockage et qu’elle n’est pas présente, arrêtez et corrigez l’environnement avant de benchmarker.

Task 6: Check for packet loss on the storage network

cr0x@server:~$ ping -c 20 -i 0.2 10.40.12.10
PING 10.40.12.10 (10.40.12.10) 56(84) bytes of data.
64 bytes from 10.40.12.10: icmp_seq=1 ttl=63 time=0.421 ms
64 bytes from 10.40.12.10: icmp_seq=2 ttl=63 time=0.389 ms
...
--- 10.40.12.10 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3811ms
rtt min/avg/max/mdev = 0.362/0.401/0.463/0.024 ms

Signification de la sortie : Pas de perte, RTT sub-millisecondes — bien. Si vous voyez de la perte ou du jitter, le stockage paraîtra « lent » parce que les retransmissions tuent la latence en queue.

Décision : Corrigez la perte/jitter réseau avant d’accuser le stockage ou de déclarer un produit « sous-performant ».

Task 7: Confirm mount options (sync/async and atime can be silent killers)

cr0x@server:~$ mount | grep /mnt/data
10.40.12.10:/vol0 on /mnt/data type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Signification de la sortie : La version NFS et rsize/wsize affectent le débit ; « relatime » réduit les écritures métadonnées.

Décision : Si le fournisseur a promis des performances sur NFSv4.2 et que vous êtes en 4.1, alignez d’abord. Si vous voyez « sync » forcé là où vous attendiez async, réévaluez les attentes de latence.

Task 8: Measure filesystem latency distribution quickly with fio (not just averages)

cr0x@server:~$ fio --name=randread --directory=/mnt/data --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=2G --time_based --runtime=60 --group_reporting
randread: (groupid=0, jobs=4): err= 0: pid=3121: Mon Jan 22 10:12:01 2026
  read: IOPS=52.1k, BW=203MiB/s (213MB/s)(12.0GiB/60s)
    slat (nsec): min=740, max=190k, avg=3200.1, stdev=4100.8
    clat (usec): min=85, max=21000, avg=510.4, stdev=980.2
     lat (usec): min=90, max=21010, avg=514.0, stdev=982.0
    clat percentiles (usec):
     |  50.00th=[  320],  90.00th=[  910],  99.00th=[ 4500],  99.90th=[14000]

Signification de la sortie : La médiane semble correcte, mais 99.9% à 14ms peut casser votre base de données. La latence en queue est la vérité ; les moyennes sont un berceuse.

Décision : Si la latence en queue dépasse les SLOs applicatifs, le produit ne convient pas à moins de modifier les patterns de charge (batching, cache, coalescence d’écritures) ou de changer de niveau.

Task 9: Verify discard/TRIM behavior (thin provisioning claims depend on it)

cr0x@server:~$ lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0

Signification de la sortie : DISC-GRAN et DISC-MAX montrent la capacité de discard. Si c’est absent, votre histoire de thin provisioning peut être une fantaisie.

Décision : Si le discard est requis pour récupérer de la capacité et qu’il n’est pas supporté de bout en bout, prévoyez une consommation de capacité réelle plus élevée ou changez de protocole/du type de périphérique.

Task 10: Check replication status and lag (roadmap “near real-time” vs reality)

cr0x@server:~$ vendorctl replication status
Pair: dc1-vol0 -> dc2-vol0
Mode: async
Last snapshot sent: 2026-01-22T10:10:12Z
Lag: 00:07:41
Queue: 1822 ops
State: healthy

Signification de la sortie : Réplication asynchrone avec un lag de 7m41s n’est pas « zéro RPO », pas « synchrone » et pas « basculement instantané ». Cela peut rester utile — simplement pas pour l’histoire qu’on vous a vendue.

Décision : Décidez si votre activité peut tolérer cet RPO. Sinon, il vous faut un design différent (vrai synchrone, réplication au niveau applicatif ou un autre produit).

Task 11: Validate “immutable snapshot” behavior with an attempted delete

cr0x@server:~$ vendorctl snapshot delete --volume vol0 --snapshot snap-2026-01-22
ERROR: snapshot is locked by retention policy until 2026-02-22T00:00:00Z

Signification de la sortie : C’est à quoi ressemble l’immuabilité : le système refuse la suppression et vous indique pourquoi.

Décision : Si un administrateur peut le supprimer quand même, ce n’est pas immuable ; c’est un « ne supprimez pas ». Traitez les affirmations de récupération contre ransomware comme non prouvées.

Task 12: Check actual data reduction ratios on real data (not vendor math)

cr0x@server:~$ vendorctl stats datareduction --volume vol0
Logical used: 12.4TiB
Physical used: 9.8TiB
Reduction ratio: 1.27:1
Dedupe: 1.05:1
Compression: 1.21:1

Signification de la sortie : Vos données se réduisent à 1.27:1, pas 5:1. C’est normal. Les affirmations fournisseurs supposent souvent des clones VDI ou des données synthétiques.

Décision : La planification de capacité doit utiliser des ratios mesurés avec des marges de sécurité. Si le business case nécessitait 4:1, le business case était du vapor.

Task 13: Find CPU saturation on the client (encryption/compression can move the bottleneck)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0-14-generic (app01) 	01/22/2026 	_x86_64_	(16 CPU)

10:14:03 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:14:04 AM  all   62.11    0.00   18.44    1.21    0.00    0.88    0.00    0.00    0.00   17.36
10:14:04 AM   3   96.00    0.00    3.00    0.00    0.00    1.00    0.00    0.00    0.00    0.00

Signification de la sortie : Un CPU est saturé. Cela peut être du chiffrement monotâche, un pilote en espace utilisateur ou un processus passerelle.

Décision : Si le goulot est le CPU client, le tuning du stockage n’aidera pas. Il vous faut du parallélisme, d’autres pilotes ou de l’offload.

Task 14: Confirm queue depth and device latency for block storage

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0-14-generic (app01) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          58.12    0.00   17.90    2.44    0.00   21.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1        820.0  52480.0     0.0   0.00    0.62    64.00   210.0  26880.0     0.0   0.00    1.10   128.00   0.35  68.00

Signification de la sortie : r_await/w_await montrent la latence ; %util indique la saturation. Une forte await avec faible util pointe souvent upstream (réseau, baie).

Décision : Si %util est bas mais await élevée, arrêtez de tuner l’hôte et commencez à tester le chemin de stockage et le comportement de l’array.

Task 15: Validate that “S3-compatible” actually supports required headers/features

cr0x@server:~$ aws --endpoint-url http://10.40.12.20:9000 s3api put-object --bucket backups --key test.txt --body /etc/hostname
{
    "ETag": "\"9b74c9897bac770ffc029102a200c5de\""
}

Signification de la sortie : Le PUT de base fonctionne. Cela ne signifie pas que le versioning, object lock ou le comportement multipart correspondent à vos outils.

Décision : Si vous avez besoin d’object lock/retention et que ce n’est pas disponible ou incompatible avec votre logiciel de sauvegarde, n’acceptez pas « compatible S3 » comme substitution aux exigences.

Task 16: Test failover mechanics, not just “status: ready”

cr0x@server:~$ vendorctl cluster failover --to-site dc2 --dry-run
Dry-run result:
  Will stop services on: dc1-gw1, dc1-gw2
  Will promote volumes: vol0, vol1
  Will update VIP: 10.40.12.10 -> 10.60.12.10
  Blocking issues:
    - quorum device unreachable
    - 2 clients have active locks on vol0
Exit code: 2

Signification de la sortie : Le système vous dit que le basculement ne fonctionnera pas maintenant, et pourquoi. C’est de l’or.

Décision : Corrigez la reachable du quorum et le comportement des verrous clients avant de déclarer la HA prête. Si la gestion des verrous est incompatible avec vos applis, il vous faut un autre plan de basculement.

Blague #2 (courte, pertinente) : Rien ne dit « haute disponibilité » comme une fonctionnalité qui devient disponible juste après le rétro de panne.

Trois micro-récits du monde de l’entreprise

Micro-récit 1 : La panne causée par une mauvaise hypothèse

L’entreprise était en cours de migration d’un SAN legacy vers une « plateforme de stockage cloud-native » vendue comme active-active entre deux datacenters. Le deck d’annonce était magnifique : écritures doublées, basculement automatique, zéro RPO. L’équipe d’architecture a conçu la nouvelle couche base de données en supposant que n’importe quel nœud pouvait écrire sur l’un ou l’autre site, rendant les fenêtres de maintenance presque mythiques.

Pendant le POC, un ingénieur fournisseur a fait une démo où il a débranché un switch et l’UI est restée verte. Tout le monde a applaudi. Personne n’a demandé quel type de charge tournait, si les écritures étaient synchrones, ni où se situait réellement le point de commit.

Des mois plus tard, en production, un arrêt d’alimentation planifié a affecté un datacenter. La plateforme a « basculé » mais la base de données a subi une vague de pics de latence de commit, puis des erreurs. La couche applicative a réessayé agressivement, créant une file d’attente qui a augmenté encore la latence. Une tempête auto-infligée classique.

La réalité post-incident : le produit n’était pas réellement active-active pour les écritures. Il l’était pour les lectures et les métadonnées, avec un primaire caché pour certains chemins d’écriture. Sous le capot, certaines opérations d’écriture étaient acquittées avant d’être réellement commitées sur le second site. Le fournisseur n’avait pas tant menti que parlé en dialecte marketing.

La correction n’a pas été un tuning magique. Ils ont changé le design : site primaire explicite par cluster de base de données, réplication synchrone gérée au niveau base de données pour les jeux de données critiques, et procédure de basculement testée incluant la mise en pause des applications. La fonctionnalité fournisseur est devenue « agréable quand elle marche », pas « fondation de la correction ».

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a acheté une baie tout-flash dont la version logicielle à venir promettait « compression en ligne sans pénalité de performance ». Leur CFO a adoré l’histoire de capacité. L’ingénierie aimait l’idée de caser plus de données dans les mêmes racks. Le plan était d’activer la compression à l’échelle dès la nouvelle release arrivée.

Quand la release est sortie, ils ont activé la compression globalement pendant une fenêtre de faible trafic. Les premières heures semblaient correctes. Puis, quand les batchs journaliers ont démarré, la latence a augmenté progressivement. Le CPU de la baie est resté en forte utilisation. Les jobs batch ont duré plus longtemps, empiétant sur les workloads interactifs. Tout le monde a souffert.

La baie faisait ce pour quoi elle avait été conçue, mais la promesse « sans pénalité » supposait un certain profil de compressibilité et un certain pattern d’écriture. Leur charge comportait des rafales de données déjà compressées, plus un mélange de petites écritures aléatoires. La compression ajoutait un coût CPU sans sauver beaucoup d’espace, et amplifiait la latence en queue.

La correction a été peu glamour : désactiver la compression pour les datasets à fort churn, la garder pour les données froides et les logs, et appliquer des politiques par volume. Ils ont aussi ajouté des tests de performance au processus de changement : si une fonctionnalité modifie le profil CPU, elle est traitée comme une nouvelle dépendance matérielle.

La leçon : les fonctionnalités « d’optimisation » sont la forme la plus courante de déception proche du vaporware. Elles livrent, elles fonctionnent, et pourtant elles ne fonctionnent pas pour vous.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise globale a évalué une nouvelle plateforme de sauvegarde promettant « sauvegardes immuables avec récupération instantanée » sur un store objet compatible S3. Le pitch fournisseur se concentrait sur la préparation contre les ransomwares : air-gapped, verrouillé, inaltérable. L’équipe sécurité était prête à signer.

Le lead SRE a insisté pour une exigence peu glamour : un script de test d’acceptation qui s’exécuterait chaque nuit dans l’environnement POC. Pas une fois. Chaque nuit. Il créerait une sauvegarde, tenterait la suppression, tenterait l’écrasement, tenterait de réduire la rétention, puis tenterait une restauration dans une VM sandbox. Chaque exécution produirait des logs, des codes de sortie et un résumé simple pass/fail.

Deux semaines après, les runs nocturnes ont commencé à échouer : le comportement « object lock » était incohérent après une mise à jour mineure. Parfois la suppression échouait (bon). Parfois la suppression réussissait (très mauvais). Le fournisseur a d’abord mis ça sur « mauvaise configuration ». Le script a rendu le problème reproductible et indéniable.

Le fournisseur a finalement reconnu un bug dans la manière dont la rétention était appliquée quand des politiques de cycle de vie étaient aussi activées. Sans le test nocturne ennuyeux, l’entreprise aurait découvert ce bug pendant un incident réel — quand l’adversaire teste vos sauvegardes pour vous.

Ils n’ont pas seulement évité un coup dur ; ils ont institutionnalisé l’idée que les affirmations de sécurité sont des affirmations opérationnelles. Si vous ne pouvez pas le tester, vous ne le possédez pas.

Erreurs courantes : symptômes → cause racine → correctif

1) « La fonctionnalité est dans le produit », mais elle manque dans votre environnement

Syndromes : L’UI affiche des options grisés ; le CLI retourne « commande inconnue » ; la doc en parle mais votre build ne l’a pas.

Cause racine : SKU/licence, limitations de région ou la fonctionnalité n’existe que dans un build plus récent que celui déployé.

Correctif : Traitez la disponibilité comme un artefact déployable : vérifiez version + état de licence dans le POC ; intégrez dans le contrat que la livraison inclut votre SKU et vos régions.

2) « Active-active » se comporte comme active-passive sous contrainte

Syndromes : Les gateways d’un site sont surchargées ; le basculement provoque des pertes de session ; la latence d’écriture augmente quand les deux sites sont utilisés.

Cause racine : Primaire caché pour la sérialisation des écritures, contraintes de quorum ou sémantiques synchrones seulement pour certaines opérations.

Correctif : Exigez des sémantiques explicites : où est le point de commit, quand est-ce acquitté et que se passe-t-il en cas de partition. Testez en induisant des partitions, pas seulement en coupant l’alimentation.

3) Les affirmations de performance s’effondrent sous charges réelles

Syndromes : Les benchmarks affichent des IOPS élevées, mais l’application est lente ; la latence 99.9p est terrible ; le débit plafonne tôt.

Cause racine : Les benchmarks fournisseur ont utilisé IO séquentiel, profondeurs de files idéales, caches chauds ou données compressibles. Votre charge est mixte et bruitée.

Correctif : Benchmarquez avec des profils fio qui correspondent à votre appli. Comparez la latence en queue et l’usage CPU. Refusez de signer sur des promesses « jusqu’à ».

4) Les sauvegardes « immuables » peuvent être supprimées par un admin

Syndromes : Un rôle admin peut supprimer la rétention, effacer des snapshots ou modifier retroactivement la configuration d’object lock.

Cause racine : L’immuabilité est implémentée comme politique, pas comme enforcement ; ou l’enforcement est mal scoped.

Correctif : Validez avec des tests destructifs. Exigez une séparation des devoirs : un principal de sécurité distinct pour les modifications de rétention, plus des logs d’audit exportables hors-plateforme.

5) L’outil de migration est promis, mais le downtime est réel

Syndromes : « Migration en direct » fonctionne pour les volumes inactifs, échoue pour les bases occupées ; le cutover demande une mise en pause d’application plus longue que prévu.

Cause racine : Le taux de pages dirty dépasse le débit de réplication ; verrous applicatifs ; support snapshot incohérent ; ou throttling pour protéger la source.

Correctif : Effectuez des répétitions de migration avec un churn de production. Mesurez les taux de dirty, planifiez les cutovers en étapes et acceptez que certaines migrations exigent des fenêtres de maintenance.

6) Observabilité traitée après coup

Syndromes : Vous ne pouvez pas voir les percentiles de latence, le lag de réplication, les taux de cache hit ou l’utilisation par locataire sans ouvrir un ticket.

Cause racine : Le fournisseur a livré la fonctionnalité cœur sans instrumentation opérationnelle ; ou les métriques existent mais ne sont pas exportables.

Correctif : Faites de la télémétrie un critère d’acceptation. Si vous ne pouvez pas exporter les métriques vers votre stack de monitoring, la fonctionnalité n’est pas prête pour la production.

Listes de contrôle / plan étape par étape

Plan étape par étape : évaluer les fonctionnalités « communiqué de presse » sans se brûler

1. Rédigez l’exigence comme un comportement observable. Exemple : « Après perte de site, les écritures continuent sous X secondes, et aucune transaction commitée n’est perdue. » Pas « active-active ».
2. Listez explicitement les exigences non fonctionnelles. Export des métriques, journaux d’audit, RBAC, procédures de mise à jour, rollback, attentes de support.
3. Exigez la matrice de support et la politique de cycle de vie. Versions OS, versions du noyau, hyperviseurs, firmwares de référence.
4. Transformez chaque affirmation en test d’acceptation. Si ça ne peut pas être testé, ça ne peut pas être digne de confiance.
5. Réalisez un POC avec injection de pannes proche de la production. Partitionnez des liens, tuez des nœuds, remplissez des disques, faites pivoter des clés, expirez des certificats.
6. Benchmarquez avec vos patterns IO. Latence en queue, mix R/W, tailles de dataset réalistes, runs cache-cold.
7. Vérifiez les workflows opérationnels. Procédure de mise à jour, procédure de restauration, provisionnement d’utilisateurs, escalade en incident.
8. Négociez les contrats sur la livraison, pas l’intention. Lie les paiements ou renouvellements à la capacité testée, pas aux slides de roadmap.
9. Concevez une stratégie de sortie dès le jour 1. Formats d’export de données, outils de migration, période de double-écriture.
10. Gardez l’architecture de secours viable. Ne supprimez pas l’ancienne plateforme tant que la nouvelle n’a pas passé des mois de tests en état stable.

Checklist de décision : quand partir

• Le fournisseur ne peut pas préciser les sémantiques précises (RPO/RTO, modèle de cohérence, comportement de commit).
• La fonctionnalité requiert une « personnalisation services professionnels » pour être utilisable.
• Télémétrie et auditabilité manquent ou sont propriétaires uniquement.
• Le POC requiert des conditions irréalistes (matériel spécial, builds privés, configs ajustées à la main) qui n’existeront pas en production.
• Le fournisseur refuse de mettre par écrit les critères de livraison.

Checklist contractuelle : cesser de payer pour du vapor

• Critères d’acceptation : tests écrits et définitions pass/fail pour les fonctionnalités clés.
• Fenêtres de livraison avec remèdes : crédits de service, droit de résiliation ou calendriers de paiement différés.
• Obligations de support : temps de réponse, chemins d’escalade, couverture d’astreinte, délais de patch.
• Droits de mise à jour : assurez-vous d’être titulaire de la version qui contient supposément la fonctionnalité.
• Portabilité des données : capacité d’exporter les données dans des formats standards sans frais punitifs.

FAQ

1) Le vaporware est-il toujours malveillant ?

Non. Une partie du vaporware vient d’ingénierie optimiste heurtant la complexité. Mais l’impact sur vos systèmes est le même : vous ne pouvez pas exécuter une promesse.

2) Quelle est la différence entre « preview » et vaporware ?

Un preview peut être légitime s’il est utilisable, testable et a des limites claires. Il devient du vaporware quand on vous pousse à en dépendre comme si c’était GA.

3) Comment résister sans passer pour un bloqueur ?

Demandez des comportements observables et des tests d’acceptation. Vous ne discutez pas ; vous définissez ce que « fini » signifie en production.

4) Et si la direction a déjà signé un contrat basé sur des fonctionnalités de roadmap ?

Basculer la conversation vers la containment du risque : isolez la dépendance, concevez un fallback et négociez des amendements liés à la livraison testée.

5) Quelles zones produits sont les plus sujettes au vaporware ?

La cohérence inter-régions, les migrations « zéro downtime », l’immuabilité anti-ransomware, le multi-cloud transparent et les fonctionnalités de performance qui prétendent « sans overhead ».

6) Comment tester correctement « active-active » ?

Testez des partitions réseau, pas seulement des défaillances de nœuds. Forcer des splits, vérifier les sémantiques de commit et mesurer le comportement client pendant le basculement.

7) Pourquoi les benchmarks fournisseur correspondent rarement à notre réalité ?

Parce qu’ils sont optimisés pour la démo : caches chauds, profondeurs de files idéales, données compressibles et conditions mono-locataire. Votre réalité est contention et entropie.

8) L’open source peut-elle aussi être du vaporware ?

Oui — surtout autour de fonctionnalités « prévues » dans les trackers d’issues. L’atténuation est la même : exécutez ce qui existe, pas ce qui est proposé.

9) Quelle est la manière la plus sûre d’adopter une nouvelle plateforme de stockage aux fonctionnalités incertaines ?

Commencez par des workloads non critiques, exigez une forte observabilité et maintenez un chemin de sortie. Promouvez seulement après des mois d’état stable et de tests de panne.

10) Si le fournisseur dit « c’est sur la roadmap », quoi demander ensuite ?

Demandez : quel build le contient ? Quelles sont les sémantiques ? Quelles sont les contraintes ? Peut-on le tester dans notre environnement POC maintenant ? Sinon, traitez-le comme absent.

Conclusion : étapes suivantes pour éviter le prochain incident

Le vaporware survit parce que les organisations traitent les annonces comme de l’inventaire. Ne le faites pas. Traitez-les comme des prévisions météo : parfois utiles, jamais structurelles.

Étapes pratiques :

1. Convertissez vos cinq principales affirmations fournisseur en tests d’acceptation que vous pouvez exécuter à la demande et selon un calendrier.
2. Refactorez les exigences en comportements observables (RPO/RTO, percentiles de latence, sémantiques de panne) et cessez d’acheter des adjectifs.
3. Établissez une règle « pas de dépendances roadmap » pour l’architecture fondamentale. Si ce n’est pas livré et testable, ce n’est pas une dépendance.
4. Faites de la télémétrie un verrou : si vous ne pouvez pas le mesurer, vous ne pouvez pas l’exploiter.
5. Négociez la livraison par écrit, y compris des remèdes. L’optimisme n’est pas exécutoire ; les contrats le sont.

Faites cela, et la prochaine fois que quelqu’un agite un communiqué de presse devant vos systèmes de production, vous aurez une réponse simple : « Cool. Montrez-moi la commande qui le prouve. »