#10ansaprès
Le cloud a tenu toutes ses promesses — sauf celles qu'on lui avait vraiment faites
Le bilan réel, dix ans après la grande migration
Agilité, économies, scalabilité : ce qu’on a vraiment gagné, ce qu’on a perdu, et ce qu’on fait semblant de ne pas voir sur la facture.
Il y a une dizaine d’années, la migration vers le cloud était présentée comme la solution à peu près tous les problèmes informatiques d’une organisation. Coûts réduits, flexibilité maximale, scalabilité infinie, fin de la gestion des serveurs physiques, capacité à innover plus vite. Les cabinets de conseil produisaient des business cases enthousiastes. Les hyperscalers déployaient des armées de commerciaux. Les DSI signaient.
Aujourd’hui, la grande majorité des organisations ont migré une partie significative de leur infrastructure vers le cloud. Et le bilan est… nuancé. Pas mauvais — mais nuancé. Ce qui est moins souvent dit, c’est ce que la migration a vraiment coûté, ce qu’elle n’a pas livré, et pourquoi la facture ressemble rarement au business case initial.
Ce que le cloud a vraiment livré — et c’est déjà beaucoup
Commençons par l’honnêteté : le cloud a tenu un certain nombre de ses promesses, et il serait injuste de ne pas le reconnaître.
La scalabilité, oui — sous conditions
La capacité à scaler à la demande est réelle. Pour des workloads variables — pics de charge, événements ponctuels, phases de croissance rapide —, le cloud offre une flexibilité que l’infrastructure on-premise ne peut pas égaler à coût comparable. Les scale-ups et les entreprises à forte saisonnalité en ont été les premiers bénéficiaires réels.
La disponibilité des services, clairement
Les niveaux de SLA des hyperscalers sont structurellement supérieurs à ce que la plupart des organisations pouvaient maintenir en interne. Les équipes d’infrastructure qui passaient leurs nuits à gérer des incidents peuvent désormais dormir plus tranquillement — même si elles ont troqué un type de problème contre un autre.
L’accès à l’innovation, indéniablement
Les services managés — bases de données, machine learning, traitement de la donnée, sécurité — ont permis à des organisations de taille moyenne d’accéder à des capacités technologiques qu’elles n’auraient jamais pu construire en interne. C’est un vrai gain démocratique dans l’écosystème IT.
Ce que le cloud n’a pas livré — et qu’on évite soigneusement de mentionner
Les économies promises ont largement disparu
C’est le sujet dont personne ne parle en réunion de direction, mais dont tout le monde parle dans les couloirs. Le business case initial promettait des économies significatives par rapport à l’infrastructure on-premise. La réalité est souvent inverse.
Les coûts de compute et de stockage ont baissé — mais les coûts de transfert de données (egress fees), les licences des services managés, les coûts de support, et surtout la complexité opérationnelle ont largement compensé ces économies. Beaucoup d’organisations ont découvert, parfois avec surprise, que leur facture cloud dépassait significativement leur budget infrastructure précédent.
La migration vers le cloud n’a pas supprimé les coûts d’infrastructure. Elle les a rendus variables, opaques, et difficiles à prévoir — ce qui est très différent de les avoir réduits.
La complexité a changé de forme — pas de niveau
L’argument selon lequel le cloud libère les équipes IT de la gestion de l’infrastructure est partiellement vrai et massivement simplifié. Oui, on ne gère plus les serveurs physiques. Mais on gère désormais la configuration des services cloud, les droits d’accès, la sécurité des environnements, la gouvernance des coûts, les contrats avec les prestataires, et l’expertise nécessaire pour tout cela.
Des équipes qui avaient dix ingénieurs infrastructure ont parfois besoin de dix ingénieurs cloud — avec des compétences différentes, plus rares, et plus chères. La pyramide de compétences a changé. La taille de la pyramide, elle, est souvent restée la même.
Le vendor lock-in a changé d’adresse, pas de nature
On a beaucoup critiqué le lock-in des éditeurs de logiciels traditionnels. Le cloud a produit un lock-in d’une nature différente mais d’une intensité comparable. Les architectures construites sur les services propriétaires d’un hyperscaler — fonctions serverless, bases de données managées, outils de machine learning — sont difficiles et coûteuses à migrer vers un autre fournisseur. Le multi-cloud est séduisant en théorie et cauchemardesque en pratique pour la plupart des organisations.
La facture cachée que personne n’a mise dans le business case
Un CFO d’ETI nous confiait récemment avoir découvert que sa facture AWS avait triplé en deux ans sans que personne dans l’organisation n’ait été en mesure d’expliquer précisément pourquoi. Ce n’est pas une anecdote isolée.
Les coûts cachés du cloud prennent plusieurs formes que les business cases initiaux oublient systématiquement.
Le FinOps : une discipline qui n’existait pas — et qui est devenue nécessaire
La gestion des coûts cloud est devenue une fonction à part entière dans les organisations matures. Le FinOps — contraction de Finance et Operations — est désormais un métier, avec ses certifications, ses outils, et ses profils spécialisés. Ce n’était dans aucun business case de 2015.
La formation et la montée en compétences
Les certifications cloud (AWS, Azure, GCP) prennent du temps et coûtent de l’argent. Les équipes IT doivent être reformées, et les profils expérimentés sur les nouvelles architectures cloud-native se négocient à des prix sensiblement supérieurs à leurs équivalents infrastructure traditionnelle.
La sécurité dans le cloud partagé
Le modèle de responsabilité partagée du cloud — le fournisseur sécurise l’infrastructure, le client sécurise ses données et ses applications — est souvent mal compris. Des incidents de sécurité majeurs impliquant des environnements cloud ont régulièrement pour origine une mauvaise configuration côté client, pas une défaillance de l’hyperscaler. La sécurité dans le cloud est une compétence nouvelle, coûteuse à acquérir.
Ce que les organisations les plus matures ont compris
Les organisations qui tirent vraiment parti du cloud ne sont pas celles qui ont migré le plus vite ou le plus massivement. Ce sont celles qui ont eu la discipline de répondre à trois questions avant de migrer chaque workload.
Est-ce que ce workload bénéficie vraiment de la scalabilité du cloud ? Un workload stable et prévisible — une base de données transactionnelle de taille fixe, un système de reporting mensuel — n’a pas besoin de la flexibilité du cloud et peut coûter moins cher on-premise ou en colocation.
Est-ce qu’on comprend le modèle de coûts complet, y compris les coûts cachés ? Les egress fees, les coûts de support, les licences des services managés, et la complexité opérationnelle doivent être intégrés dans le calcul.
Est-ce qu’on a les compétences pour opérer cela correctement ? Une migration réussie techniquement qui n’est pas opérée correctement faute de compétences produit des incidents, des coûts non maîtrisés, et des risques de sécurité.
Le cloud n’est pas une destination — c’est un outil. Comme tous les outils, son utilité dépend entièrement de la façon dont on l’utilise. Et contrairement à ce qu’on nous a dit, il ne se pilote pas tout seul.
Ce qu’il faut retenir
Le cloud est une technologie transformative — mais ses bénéfices réels ne correspondent pas toujours aux promesses initiales, et ses coûts et complexités réels sont systématiquement sous-estimés dans les décisions de migration.
Les organisations qui en tirent le meilleur parti sont celles qui l’abordent avec pragmatisme plutôt qu’idéologie : cloud pour ce qui en bénéficie, on-premise ou colocation pour ce qui n’en a pas besoin, et une gouvernance rigoureuse des coûts et de la sécurité dans tous les cas.
Chez Kalyptus, nous accompagnons régulièrement des organisations dans le recrutement des profils qui permettent de piloter cette complexité — architectes cloud, responsables FinOps, CISO spécialisés dans les environnements cloud. Si vous cherchez à renforcer votre leadership sur ces sujets, nous sommes heureux d’en parler.
Le bilan réel, dix ans après la grande migration
Agilité, économies, scalabilité : ce qu’on a vraiment gagné, ce qu’on a perdu, et ce qu’on fait semblant de ne pas voir sur la facture.
Il y a une dizaine d’années, la migration vers le cloud était présentée comme la solution à peu près tous les problèmes informatiques d’une organisation. Coûts réduits, flexibilité maximale, scalabilité infinie, fin de la gestion des serveurs physiques, capacité à innover plus vite. Les cabinets de conseil produisaient des business cases enthousiastes. Les hyperscalers déployaient des armées de commerciaux. Les DSI signaient.
Aujourd’hui, la grande majorité des organisations ont migré une partie significative de leur infrastructure vers le cloud. Et le bilan est… nuancé. Pas mauvais — mais nuancé. Ce qui est moins souvent dit, c’est ce que la migration a vraiment coûté, ce qu’elle n’a pas livré, et pourquoi la facture ressemble rarement au business case initial.
Ce que le cloud a vraiment livré — et c’est déjà beaucoup
Commençons par l’honnêteté : le cloud a tenu un certain nombre de ses promesses, et il serait injuste de ne pas le reconnaître.
La scalabilité, oui — sous conditions
La capacité à scaler à la demande est réelle. Pour des workloads variables — pics de charge, événements ponctuels, phases de croissance rapide —, le cloud offre une flexibilité que l’infrastructure on-premise ne peut pas égaler à coût comparable. Les scale-ups et les entreprises à forte saisonnalité en ont été les premiers bénéficiaires réels.
La disponibilité des services, clairement
Les niveaux de SLA des hyperscalers sont structurellement supérieurs à ce que la plupart des organisations pouvaient maintenir en interne. Les équipes d’infrastructure qui passaient leurs nuits à gérer des incidents peuvent désormais dormir plus tranquillement — même si elles ont troqué un type de problème contre un autre.
L’accès à l’innovation, indéniablement
Les services managés — bases de données, machine learning, traitement de la donnée, sécurité — ont permis à des organisations de taille moyenne d’accéder à des capacités technologiques qu’elles n’auraient jamais pu construire en interne. C’est un vrai gain démocratique dans l’écosystème IT.
Ce que le cloud n’a pas livré — et qu’on évite soigneusement de mentionner
Les économies promises ont largement disparu
C’est le sujet dont personne ne parle en réunion de direction, mais dont tout le monde parle dans les couloirs. Le business case initial promettait des économies significatives par rapport à l’infrastructure on-premise. La réalité est souvent inverse.
Les coûts de compute et de stockage ont baissé — mais les coûts de transfert de données (egress fees), les licences des services managés, les coûts de support, et surtout la complexité opérationnelle ont largement compensé ces économies. Beaucoup d’organisations ont découvert, parfois avec surprise, que leur facture cloud dépassait significativement leur budget infrastructure précédent.
La migration vers le cloud n’a pas supprimé les coûts d’infrastructure. Elle les a rendus variables, opaques, et difficiles à prévoir — ce qui est très différent de les avoir réduits.
La complexité a changé de forme — pas de niveau
L’argument selon lequel le cloud libère les équipes IT de la gestion de l’infrastructure est partiellement vrai et massivement simplifié. Oui, on ne gère plus les serveurs physiques. Mais on gère désormais la configuration des services cloud, les droits d’accès, la sécurité des environnements, la gouvernance des coûts, les contrats avec les prestataires, et l’expertise nécessaire pour tout cela.
Des équipes qui avaient dix ingénieurs infrastructure ont parfois besoin de dix ingénieurs cloud — avec des compétences différentes, plus rares, et plus chères. La pyramide de compétences a changé. La taille de la pyramide, elle, est souvent restée la même.
Le vendor lock-in a changé d’adresse, pas de nature
On a beaucoup critiqué le lock-in des éditeurs de logiciels traditionnels. Le cloud a produit un lock-in d’une nature différente mais d’une intensité comparable. Les architectures construites sur les services propriétaires d’un hyperscaler — fonctions serverless, bases de données managées, outils de machine learning — sont difficiles et coûteuses à migrer vers un autre fournisseur. Le multi-cloud est séduisant en théorie et cauchemardesque en pratique pour la plupart des organisations.
La facture cachée que personne n’a mise dans le business case
Un CFO d’ETI nous confiait récemment avoir découvert que sa facture AWS avait triplé en deux ans sans que personne dans l’organisation n’ait été en mesure d’expliquer précisément pourquoi. Ce n’est pas une anecdote isolée.
Les coûts cachés du cloud prennent plusieurs formes que les business cases initiaux oublient systématiquement.
Le FinOps : une discipline qui n’existait pas — et qui est devenue nécessaire
La gestion des coûts cloud est devenue une fonction à part entière dans les organisations matures. Le FinOps — contraction de Finance et Operations — est désormais un métier, avec ses certifications, ses outils, et ses profils spécialisés. Ce n’était dans aucun business case de 2015.
La formation et la montée en compétences
Les certifications cloud (AWS, Azure, GCP) prennent du temps et coûtent de l’argent. Les équipes IT doivent être reformées, et les profils expérimentés sur les nouvelles architectures cloud-native se négocient à des prix sensiblement supérieurs à leurs équivalents infrastructure traditionnelle.
La sécurité dans le cloud partagé
Le modèle de responsabilité partagée du cloud — le fournisseur sécurise l’infrastructure, le client sécurise ses données et ses applications — est souvent mal compris. Des incidents de sécurité majeurs impliquant des environnements cloud ont régulièrement pour origine une mauvaise configuration côté client, pas une défaillance de l’hyperscaler. La sécurité dans le cloud est une compétence nouvelle, coûteuse à acquérir.
Ce que les organisations les plus matures ont compris
Les organisations qui tirent vraiment parti du cloud ne sont pas celles qui ont migré le plus vite ou le plus massivement. Ce sont celles qui ont eu la discipline de répondre à trois questions avant de migrer chaque workload.
Est-ce que ce workload bénéficie vraiment de la scalabilité du cloud ? Un workload stable et prévisible — une base de données transactionnelle de taille fixe, un système de reporting mensuel — n’a pas besoin de la flexibilité du cloud et peut coûter moins cher on-premise ou en colocation.
Est-ce qu’on comprend le modèle de coûts complet, y compris les coûts cachés ? Les egress fees, les coûts de support, les licences des services managés, et la complexité opérationnelle doivent être intégrés dans le calcul.
Est-ce qu’on a les compétences pour opérer cela correctement ? Une migration réussie techniquement qui n’est pas opérée correctement faute de compétences produit des incidents, des coûts non maîtrisés, et des risques de sécurité.
Le cloud n’est pas une destination — c’est un outil. Comme tous les outils, son utilité dépend entièrement de la façon dont on l’utilise. Et contrairement à ce qu’on nous a dit, il ne se pilote pas tout seul.
Ce qu’il faut retenir
Le cloud est une technologie transformative — mais ses bénéfices réels ne correspondent pas toujours aux promesses initiales, et ses coûts et complexités réels sont systématiquement sous-estimés dans les décisions de migration.
Les organisations qui en tirent le meilleur parti sont celles qui l’abordent avec pragmatisme plutôt qu’idéologie : cloud pour ce qui en bénéficie, on-premise ou colocation pour ce qui n’en a pas besoin, et une gouvernance rigoureuse des coûts et de la sécurité dans tous les cas.
Chez Kalyptus, nous accompagnons régulièrement des organisations dans le recrutement des profils qui permettent de piloter cette complexité — architectes cloud, responsables FinOps, CISO spécialisés dans les environnements cloud. Si vous cherchez à renforcer votre leadership sur ces sujets, nous sommes heureux d’en parler.