J’ai vu un directeur technique perdre 14 000 euros de budget en un seul trimestre parce qu’il pensait que la question How Many Megs In A Gigabyte était un détail pour les techniciens de premier niveau. Il avait validé un contrat de réplication de données pour un parc de serveurs en se basant sur un calcul approximatif à base de mille, alors que l'infrastructure réelle et le système de facturation de son fournisseur utilisaient une base binaire. Au moment où les logs de transfert ont commencé à s'accumuler, l'écart de 7,3 % entre sa prévision et la réalité a fait exploser les quotas de bande passante, déclenchant des pénalités de dépassement automatiques. Ce genre d'erreur n'arrive pas parce que les gens sont incompétents, mais parce qu'ils oublient que dans l'industrie, la définition d'une unité de mesure dépend entièrement de qui vous vend le service et de la couche logicielle qui l'analyse.
La confusion entre le marketing et la réalité binaire
L'erreur la plus fréquente que je rencontre réside dans la croyance aveugle que tout le monde utilise la même règle de calcul. Si vous achetez un disque dur de 1 To, vous vous attendez à voir 1 000 Go s'afficher sur votre écran. Pourtant, dès que vous le branchez sur un système Windows, vous voyez s'afficher environ 931 Go. Ce n'est pas une arnaque du fabricant, c'est une divergence fondamentale entre le système décimal des vendeurs de matériel et le système binaire des systèmes d'exploitation. Le fabricant utilise des puissances de 10 ($10^3 = 1 000$), tandis que votre machine compte en puissances de 2 ($2^{10} = 1 024$).
Quand vous demandez How Many Megs In A Gigabyte, la réponse dépend de l'étiquette. Si vous parlez de mégaoctets (Mo) dans un contexte de stockage marketing, c'est 1 000. Si vous parlez de Mebioctets (MiB), l'unité standardisée par la Commission Électrotechnique Internationale (CEI) depuis 1998 pour lever cette ambiguïté, c'est 1 024. Le problème, c'est que presque personne n'utilise les termes MiB ou GiB dans les réunions de budget. On continue de dire "Giga" pour tout, et c'est là que le fossé se creuse. Dans mon expérience, ne pas clarifier cette unité avant de signer un contrat d'hébergement ou de transit de données est le moyen le plus rapide de voir ses prévisions de coûts s'effondrer dès le deuxième mois.
How Many Megs In A Gigabyte et le piège des sauvegardes immuables
Une autre erreur coûteuse concerne la planification de la rétention des données. Imaginez une entreprise qui doit sauvegarder 500 To de données sensibles. L'architecte système fait ses calculs sur une base de 1 000, prévoyant un volume spécifique pour ses clichés instantanés. Mais le logiciel de sauvegarde, lui, calcule en base 2.
L'illusion de la capacité disponible
Le logiciel indique qu'il reste 10 % d'espace. En réalité, si l'on suit la logique des fabricants de baies de stockage, ces 10 % représentent un volume physique bien moindre que prévu. Quand le système atteint sa limite réelle, les processus de nettoyage échouent souvent. J'ai assisté à une situation où une base de données de production s'est figée pendant six heures parce que le volume de stockage "disponible" n'était qu'une estimation logicielle optimiste qui ne tenait pas compte de la réserve de sécurité du système de fichiers (souvent 5 % sur Linux).
La dérive des métadonnées
On oublie aussi que stocker un fichier d'un gigaoctet ne consomme pas exactement un gigaoctet. Il y a les métadonnées, les sommes de contrôle et l'indexation. Si vous multipliez cette petite erreur d'appréciation par des millions de fichiers, vous vous retrouvez avec une différence de plusieurs téraoctets. Le coût de stockage à long terme sur AWS S3 ou Azure Blob Storage ne pardonne pas ces approximations. On finit par payer pour du vide ou, pire, par supprimer des données historiques précieuses pour libérer de l'espace en urgence parce qu'on n'a pas su anticiper l'occupation réelle au bloc près.
Le désastre de la bande passante réseau et des limites de débit
Dans le monde des réseaux, tout se complique encore. Les fournisseurs d'accès Internet (FAI) et les opérateurs de réseaux de diffusion de contenu (CDN) vendent de la vitesse en mégabits par seconde (Mbps) mais facturent souvent le volume transféré en gigaoctets (Go). Ici, le rapport n'est pas seulement de 1 000 ou 1 024, il faut aussi diviser par 8 pour passer des bits aux octets.
J'ai vu une agence de streaming lancer une campagne sans comprendre cette distinction. Ils avaient calculé qu'un flux de 5 Mbps tiendrait dans leur forfait mensuel en supposant un calcul simplifié. Ils n'avaient pas intégré que les en-têtes de paquets TCP/IP ajoutent une surcharge d'environ 5 % à 10 % sur chaque transfert. Leur estimation de volume total était fausse dès le départ. Pour éviter cela, vous devez systématiquement appliquer un coefficient de sécurité de 15 % sur vos calculs de transfert. Ne vous demandez pas seulement combien de données vous avez à envoyer, mais combien de données le protocole va réellement générer pour transporter vos fichiers. Si vous ne le faites pas, votre facture de sortie de données (egress fees) sera votre pire cauchemar financier à la fin du mois.
Comparaison concrète : Le projet de migration de données
Pour comprendre l'impact financier, regardons un scénario de migration de 100 To vers le cloud.
L'approche théorique (La mauvaise méthode) L'ingénieur prévoit de migrer 100 000 Go (en pensant que 1 To = 1 000 Go). Il estime le temps de transfert avec une connexion de 1 Gbps, calculant simplement $100 000 / 1$ pour obtenir un nombre d'heures théorique. Il ne prend pas en compte la latence, la surcharge du protocole, ni le fait que son stockage cible compte en TiB (base 1 024). Résultat : la migration prend 12 jours de plus que prévu, l'entreprise paie des frais de double stockage pendant cette période, et le budget explose de 30 %.
L'approche pratique (La bonne méthode) L'expert commence par valider si le prestataire cloud facture en Go (décimal) ou en GiB (binaire). Il sait que 100 To "marketing" ne correspondent qu'à environ 90,9 TiB de capacité réelle exploitable dans le cloud. Il calcule le volume de transfert en incluant 10 % de surcharge protocolaire. Il prévoit une fenêtre de migration basée sur 80 % de la bande passante théorique pour absorber les variations de trafic. Le projet se termine avec deux jours d'avance sur la marge de sécurité, et le coût final correspond au devis initial à 2 % près.
L'erreur fatale du provisionnement dynamique
Beaucoup pensent que le provisionnement dynamique (thin provisioning) résout le problème de l'incertitude des volumes. C'est une erreur classique de gestion d'infrastructure. On se dit que ce n'est pas grave de ne pas savoir exactement How Many Megs In A Gigabyte car le système s'adaptera tout seul en consommant uniquement ce dont il a besoin.
C’est un pari dangereux. Dans un environnement virtualisé, si vous allouez trop d'espace virtuel en vous basant sur des calculs erronés, vous risquez de provoquer un "overcommit" mortel. Si tous vos systèmes décident d'écrire des données simultanément, votre stockage physique sature instantanément et toutes vos machines virtuelles passent en mode lecture seule ou plantent. J'ai vu un centre de données entier s'arrêter parce que trois administrateurs différents avaient utilisé des méthodes de calcul différentes pour leurs quotas, pensant que le stockage physique était une ressource infinie. La solution est de toujours surveiller l'occupation physique réelle (en base 2) et de ne jamais se fier aux rapports de consommation logique du système d'exploitation qui utilise souvent une base 10 pour être "plus lisible" pour l'utilisateur.
La gestion des bases de données et l'indexation massive
Dans le domaine des bases de données, la question de l'unité de mesure devient une question de performance pure. Quand on manipule des milliards de lignes, la taille de chaque champ compte. Si vous concevez une table en pensant que vous avez une marge de manœuvre confortable, vous risquez d'atteindre les limites de la mémoire vive (RAM) de votre serveur bien plus tôt que prévu.
La RAM est toujours calculée en base binaire stricte. Un serveur de 64 Go de RAM possède exactement $64 \times 1 024$ Mo de capacité. Cependant, les fichiers de données sur le disque peuvent être rapportés différemment par les outils de surveillance. Si votre index dépasse la taille de la RAM disponible à cause d'une mauvaise estimation du volume de données, vos performances vont s'effondrer car le système devra faire des allers-retours incessants avec le disque (swap). Pour éviter cela, j'impose toujours une règle simple : tous les calculs de capacité de base de données doivent être effectués en MiB et GiB, jamais en unités décimales. C'est la seule façon de garantir que l'index restera en mémoire et que les temps de réponse ne passeront pas de quelques millisecondes à plusieurs secondes.
Vérification de la réalité
Soyons honnêtes : personne ne va vous féliciter parce que vous connaissez la différence exacte entre un décimal et un binaire. Par contre, on vous tiendra pour responsable quand le projet dépassera le budget ou que le stockage sera saturé en pleine période de pointe. La réalité du terrain, c'est que les outils que nous utilisons sont incohérents. Linux vous donnera souvent des chiffres en base 2 (GiB) mais les étiquettera "GB". Windows fera la même chose. Les fabricants de disques resteront sur la base 10 car cela fait paraître leurs produits plus gros.
Pour réussir, vous devez arrêter de supposer. Avant chaque projet d'infrastructure, de sauvegarde ou de migration cloud, vous devez poser une question simple mais brutale à vos fournisseurs : "Utilisez-vous la norme SI (1 000) ou la norme CEI (1 024) pour votre facturation et vos rapports ?" Si vous ne recevez pas une réponse claire, prenez le chiffre le plus pessimiste pour votre budget. Dans ce domaine, l'optimisme est une faute professionnelle qui se paie en milliers d'euros. Ne cherchez pas la perfection mathématique, cherchez la sécurité opérationnelle. Si votre calcul ne prévoit pas une marge d'erreur de 10 % pour absorber ces variations de définition, vous n'avez pas un plan, vous avez un vœu pieux.
