Le cloud n'est pas qu'une bascule technique, c'est d'abord une bascule comptable. Quand vous migrez, vous arrêtez d'acheter du matériel amorti sur 5 ans (CAPEX) pour louer des ressources à l'usage (OPEX). Cette transformation change qui décide, quand, avec quel budget, et ouvre la porte à des dérives financières que les DAF redoutent à juste titre. Ce guide pose les deux modèles, explique pourquoi la bascule est puissante mais piégeuse, et vous donne les réflexes pour ne pas perdre le contrôle.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La différence comptable entre CAPEX et OPEX appliquée à l'IT
- Pourquoi le cloud impose une bascule vers l'OPEX
- Les conséquences pratiques sur la gouvernance et la prise de décision
- Les pièges des deux modèles, avec exemples chiffrés sur 3 ans
- Quand un mix CAPEX/OPEX reste la bonne réponse en 2026
Prérequis : connaître les bases du cloud. Si besoin, démarrez par Définition et promesses du cloud.
1. CAPEX et OPEX : la définition comptable
Section intitulée « 1. CAPEX et OPEX : la définition comptable »Avant de parler cloud, il faut poser le vocabulaire. Ces deux acronymes viennent de la comptabilité d'entreprise et structurent la manière dont toute dépense IT est classée dans les états financiers.
CAPEX, Capital Expenditure
Section intitulée « CAPEX, Capital Expenditure »Une dépense d'investissement correspond à l'achat d'un actif durable que l'entreprise va utiliser pendant plusieurs années. En IT, on parle de serveurs physiques, de baies de stockage, de matériel réseau, de licences perpétuelles. Comptablement, le bien est immobilisé au bilan et son coût est amorti sur sa durée d'usage prévue, typiquement 3 à 5 ans pour du matériel informatique.
Concrètement, si vous achetez un cluster de 10 serveurs à 8 000 € pièce, vous engagez 80 000 € de trésorerie au moment de l'achat, mais vous ne constatez en charge que 16 000 € par an pendant 5 ans. Le bilan affiche un actif qui se déprécie, le compte de résultat absorbe l'effort progressivement.
OPEX, Operating Expenditure
Section intitulée « OPEX, Operating Expenditure »Une dépense d'exploitation est consommée immédiatement et entièrement comptabilisée en charge sur l'exercice où elle est engagée. En IT classique, on retrouve dans cette catégorie l'électricité du datacenter, le personnel d'exploitation, les abonnements logiciels, la maintenance. Pas d'amortissement, pas d'immobilisation : la facture du mois est intégralement déduite du résultat du mois.
L'OPEX est plus simple à gérer comptablement, mais il impacte directement le résultat d'exploitation et donc la rentabilité affichée. C'est pourquoi un DAF historique préfère souvent le CAPEX : un investissement de 80 000 € disparaît dans le bilan, alors qu'une location annuelle de 16 000 € pèse chaque année sur le résultat.
2. Pourquoi le cloud impose la bascule vers l'OPEX
Section intitulée « 2. Pourquoi le cloud impose la bascule vers l'OPEX »Le cloud computing est, par construction, un service consommé à la demande. Vous ne possédez ni le serveur physique, ni le datacenter, ni les disques. Vous louez un service que le fournisseur vous facture mensuellement. Cette mécanique relève donc du contrat de services, et tombe naturellement dans la catégorie OPEX.
Cette bascule n'est pas un effet de bord, c'est le cœur de la proposition de valeur cloud. Plus besoin de bloquer 80 000 € de trésorerie pour démarrer un projet : vous lancez 10 instances pour 200 € par mois, vous arrêtez quand le projet stoppe. La friction d'achat disparaît, ce qui est libérateur pour les équipes produit et redoutable pour les DAF qui ont perdu leur point de contrôle naturel, le bon de commande matériel.
3. Combien coûte réellement un cluster de 20 VMs sur 3 ans ?
Section intitulée « 3. Combien coûte réellement un cluster de 20 VMs sur 3 ans ? »Un cluster de 20 machines 4 vCPU / 8 Gio tournant en permanence coûte environ 113 000 USD de ressources cloud sur 3 ans, contre environ 250 000 € d'achat et d'exploitation en propre sur la même période et le même dimensionnement. Mais ce verdict tient entièrement aux hypothèses qui le produisent, et il s'inverse dès qu'on en change une. La suite les pose une par une, avec la formule, pour que vous puissiez refaire le calcul avec vos propres chiffres.
Les entrées du calcul
Section intitulée « Les entrées du calcul »Un comparatif n'a de valeur que si ses entrées sont visibles. Voici les miennes, que vous devez remplacer par les vôtres avant d'en tirer la moindre décision.
| Entrée | Valeur retenue ici | Où trouver la vôtre |
|---|---|---|
| Nombre de machines | 20 | Votre inventaire de production |
| Gabarit | 4 vCPU, 8 Gio | c5.xlarge ou équivalent chez votre fournisseur |
| Stockage par machine | 100 Go bloc | Volume racine plus données |
| Taux d'utilisation | 100 %, allumé en permanence | Métriques d'usage sur 3 mois |
| Durée d'amortissement | 3 ans | Politique comptable de l'entreprise |
| Région | Paris (eu-west-3) | Contrainte de résidence |
| Heures facturées par mois | 730 | Convention : 8 760 h / 12 |
Les tarifs, relevés à la source
Section intitulée « Les tarifs, relevés à la source »| Ressource | Tarif publié | Sur 20 machines, par mois |
|---|---|---|
Calcul c5.xlarge | 0,2020 USD/h | 20 × 0,2020 × 730 = 2 949 USD |
| Stockage bloc gp3 | 0,0928 USD/Go-mois | 20 × 100 × 0,0928 = 186 USD |
| Total ressources | 3 135 USD / mois |
La formule tient en une ligne, et c'est elle qu'il faut retenir plutôt que le résultat :
coût mensuel = machines × (prix_horaire × heures_par_mois) + machines × (Go_par_machine × prix_Go_mois)Sur 36 mois, cela donne 112 860 USD de ressources. Il faut y ajouter ce que le cloud ne fournit pas gratuitement, et c'est là que la plupart des comparatifs trichent.
Ce que le cloud ne rend pas gratuit
Section intitulée « Ce que le cloud ne rend pas gratuit »| Poste | On-premise (CAPEX) | Cloud (OPEX) |
|---|---|---|
| Matériel serveurs | 60 000 € amortis sur 3 ans | 0 € |
| Stockage | 25 000 € de baie, amortis sur 5 ans | facturé à part, 186 USD / mois ci-dessus |
| Réseau (switches, pare-feu) | 15 000 € amortis sur 7 ans | réseau virtuel inclus, mais passerelle NAT, équilibreur et trafic sortant facturés |
| Datacenter / colocation | 6 000 € / an (énergie + baie) | 0 € |
| Licences hyperviseur | 8 000 € / an (vSphere) | 0 € |
| Support | 12 % du matériel / an | payant dès qu'on veut ouvrir un ticket sur un incident de production, tarif proportionnel à la dépense |
| Personnel exploitation | 0,5 ETP, soit ~35 000 € / an | 0,2 ETP, soit ~14 000 € / an |
| Ressources cloud | 0 € | 3 135 USD / mois, soit ~112 900 USD sur 3 ans |
Ce qui fait basculer le verdict
Section intitulée « Ce qui fait basculer le verdict »Le résultat ci-dessus vaut pour ce jeu d'hypothèses. Trois variables le retournent, dans un sens comme dans l'autre.
Le taux d'utilisation réel. L'hypothèse retenue est la plus défavorable au cloud : 20 machines allumées en permanence. Si votre charge moyenne est de 7 machines avec des pics à 20, la ligne calcul tombe à environ 1 032 USD par mois, tandis que le on-premise reste dimensionné pour le pic et ne bouge pas d'un euro. À l'inverse, sur une charge parfaitement stable 24/7, le cloud à la demande perd son principal avantage.
L'engagement. Une réservation sur 3 ans réduit fortement le prix du calcul, au prix d'un engagement ferme. C'est le levier que tout comparatif honnête doit mentionner, avec sa contrepartie, traitée plus bas.
Le risque de panne matérielle. Sur 20 serveurs amortis 3 ans, quelques défaillances de disque et au moins une carte mère sont statistiquement à prévoir. Le coût de remplacement, le délai d'indisponibilité et la qualité du contrat de support n'apparaissent pas dans la colonne CAPEX, mais ils existent.
Le coût de la fin de vie. Au bout de 3 ans, le on-premise repart à zéro : nouveau cycle d'achat, migration des données, réinstallation. Côté cloud, on change de génération d'instance en modifiant une ligne de Terraform.
4. Conséquences pratiques de la bascule
Section intitulée « 4. Conséquences pratiques de la bascule »Au-delà de la mécanique comptable, la bascule CAPEX → OPEX change qui décide quoi, et c'est là que se jouent les vraies réussites et les vrais échecs des migrations cloud.
🔓 Disparition du comité d'investissement
Avant : pour acheter 5 serveurs, il fallait passer par un comité budgétaire trimestriel, monter un dossier, justifier le ROI, attendre 6 mois la livraison.
Après : un développeur avec un compte cloud peut provisionner 5 instances en 90 secondes via Terraform, sans demander à personne.
Conséquence positive : agilité produit décuplée, MVP livrables en jours. Conséquence négative : perte du contrôle financier traditionnel.
📉 Imprévisibilité de la facture mensuelle
Avant : la dépense IT était prévisible, vous saviez en janvier ce que vous paieriez en décembre.
Après : la facture cloud peut doubler en un mois sans changement intentionnel (pic d'usage, fuite de logs, instance oubliée, attaque DDoS amplifiée).
Mitigation : budgets cloud avec alarmes, FinOps en place dès le J1, pas en année 2.
🔐 Fin du « possédons-nous nos données »
Avant : les données vivent sur vos disques, dans votre datacenter, sous votre juridiction.
Après : elles vivent chez le fournisseur, soumises au contrat et à la juridiction du fournisseur, un sujet à part entière côté souveraineté.
Implication : la bascule comptable a aussi une dimension juridique que les DAF n'ont historiquement pas pris en compte.
📊 Difficulté à classifier les flux
Avant : un serveur acheté en 2024 reste classé en immobilisation 2024 jusqu'en 2029.
Après : la facture cloud du mois mélange compute (production), dev/test, R&D, et il faut un système de tagging rigoureux pour reconstituer qui consomme quoi.
Réponse : politique de tagging obligatoire (CostCenter, Project, Environment, Owner) appliquée par policy.
5. Les pièges des deux modèles
Section intitulée « 5. Les pièges des deux modèles »Aucun des deux modèles n'est universellement meilleur. Voici les pièges réels qu'il faut connaître pour ne pas se laisser bercer par le marketing fournisseur.
Pièges du modèle CAPEX (on-premise)
Section intitulée « Pièges du modèle CAPEX (on-premise) »La sur-capacité dormante. Comme vous dimensionnez pour le pic, vous payez 24/7 des serveurs qui tournent à 20 % de charge. La consommation électrique est constante, l'amortissement est constant, mais le service rendu suit la charge. C'est l'inefficience structurelle du modèle.
L'obsolescence forcée. Au bout de 3 à 5 ans, le matériel sort du cycle de support constructeur. Vous devez racheter en bloc, ce qui crée des pics CAPEX douloureux qui repoussent les modernisations légitimes.
La rigidité opérationnelle. Pour passer de 20 à 30 serveurs, comptez 3 à 6 mois entre la décision et la mise en production. Le cycle d'achat tue les opportunités courtes.
Pièges du modèle OPEX (cloud)
Section intitulée « Pièges du modèle OPEX (cloud) »Confondre OPEX cloud et OPEX SaaS. Quand vous payez un abonnement mensuel par utilisateur pour un CRM, vous payez un service applicatif fini. Quand vous payez 147 USD par mois une instance c5.xlarge, vous payez juste le droit d'utiliser une machine virtuelle : il faut encore monter l'application, l'opérer, la sauvegarder et la sécuriser. Le « tout inclus » du cloud est un mythe que les commerciaux entretiennent.
Les coûts cachés de la migration. Aucun comparatif honnête n'oublie le coût de migration, celui de la formation des équipes, avec les mois de productivité dégradée qui vont avec, et celui de la réversibilité future si vous voulez sortir. Ces trois postes ne se chiffrent pas dans l'absolu : ils dépendent du nombre d'applications, de leur couplage à l'infrastructure existante et du niveau de départ des équipes. Les estimer sur votre propre périmètre fait partie du travail de cadrage, et un comparatif qui les annonce en pourcentage fixe se trompe presque toujours.
L'illusion de la flexibilité. Le cloud promet la flexibilité, mais quand vous engagez des instances réservées sur 3 ans pour obtenir une remise importante, vous re-créez un CAPEX déguisé en OPEX, sans la propriété du matériel à la fin. Vous avez alors le pire des deux mondes : engagement long terme et zéro actif au bilan.
6. Choisir entre CAPEX et OPEX selon le profil de workload
Section intitulée « 6. Choisir entre CAPEX et OPEX selon le profil de workload »Plutôt qu'un basculement total dans un sens ou dans l'autre, le choix dépend du profil de chaque workload. Voici les profils où chaque modèle est généralement plus adapté.
Profils où le CAPEX (on-premise) reste compétitif :
- Bases de données monolithiques 24/7 sur plusieurs années, l'amortissement matériel devient compétitif quand l'usage est stable et prolongé.
- Workloads à très fort egress, le coût de sortie de données mensuelle peut à lui seul peser lourd dans la balance vs un serveur on-premise dédié.
- Données sensibles sous contraintes réglementaires fortes, voir Souveraineté technologique de la stack.
Profils où l'OPEX (cloud) est généralement plus avantageux :
- MVP et phases d'innovation, la friction d'achat ralentit les itérations.
- Charges variables, dès que le rapport entre le creux et le pic devient significatif. Le seuil exact dépend de votre grille tarifaire : calculez-le plutôt que de retenir un ratio tout fait.
- Sites secondaires de DR, payer un datacenter complet pour quelques jours d'usage par an est généralement moins efficient qu'une réplication cloud.
Dans la pratique, beaucoup d'organisations adoptent une architecture hybride qui combine on-premise pour les workloads stables et cloud pour le variable. Ce mix est une décision rationnelle qui se calcule sur un TCO 3 à 5 ans, pas un échec de migration.
À retenir
Section intitulée « À retenir »- CAPEX = achat amorti au bilan, OPEX = location en charge au compte de résultat. C'est la différence comptable fondamentale.
- Le cloud bascule mécaniquement vers l'OPEX, c'est sa proposition de valeur première et son piège principal.
- La bascule change qui décide : disparition du comité d'investissement, montée des coûts décentralisés, besoin urgent de gouvernance FinOps.
- Aucun modèle n'est universellement meilleur : le bon comparatif s'appuie sur un TCO 3 à 5 ans, sur un profil d'usage réaliste, et n'oublie ni les coûts cachés ni les engagements long terme.
- Le mix CAPEX/OPEX reste souvent l'optimum réel pour une ETI installée, ce n'est pas un échec de migration, c'est une décision rationnelle.