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. Comparaison concrète sur 3 ans
Section intitulée « 3. Comparaison concrète sur 3 ans »Pour rendre la bascule tangible, voici un cas chiffré courant dans le marché : déployer un cluster applicatif de 20 VMs pour une plateforme SaaS. On compare le scénario achat on-premise au scénario location cloud, en restant honnête sur les coûts cachés des deux côtés.
Hypothèse — cluster 20 VMs équivalentes c5.xlarge AWS
Section intitulée « Hypothèse — cluster 20 VMs équivalentes c5.xlarge AWS »| Poste | On-premise (CAPEX) | Cloud (OPEX) |
|---|---|---|
| Matériel serveurs | 60 000 € amortis sur 3 ans | 0 € |
| Stockage SAN dédié | 25 000 € amortis sur 5 ans | inclus dans la VM (EBS) |
| Réseau (switches, FW) | 15 000 € amortis sur 7 ans | inclus (VPC, SG) |
| Datacenter / colocation | 6 000 € / an (énergie + rack) | 0 € |
| Licences hyperviseur | 8 000 € / an (vSphere) | 0 € |
| Maintenance + support | 12 % du matériel / an | 0 € (inclus) |
| Personnel exploitation | 0,5 ETP soit ~35 000 € / an | 0,2 ETP soit ~14 000 € / an |
| Coût VMs cloud | 0 € | ~700 € / VM / mois × 20 = 14 000 € / mois |
| Total brut sur 3 ans | ~250 000 € | ~504 000 € |
À première lecture, le on-premise écrase le cloud : moitié prix sur 3 ans. Et c’est généralement ce que le DAF retient. Sauf que cette lecture occulte trois variables critiques que je vois ignorées huit fois sur dix dans les comparatifs sortis par les commerciaux on-prem.
Les variables que le tableau brut cache
Section intitulée « Les variables que le tableau brut cache »La capacité utilisée moyenne. Le on-premise est dimensionné pour le pic : si votre application a un pic à 20 VMs et une moyenne à 7 VMs, vous payez quand même les 20 VMs au prix fort, 24/7. En cloud, vous payez les 7 VMs en moyenne et vous montez à 20 uniquement les jours de pic. Sur ce profil typique, la facture cloud passe de 504 000 € à ~180 000 €, et le calcul s’inverse complètement.
Le risque de panne hardware. Sur 20 serveurs amortis 3 ans, vous aurez statistiquement 2 pannes disque et 1 carte mère HS sur la période. Le coût de remplacement, le délai d’indisponibilité, la fragilité du contrat de support — tout ça n’apparaît pas dans le tableau, mais s’incarne dans des nuits blanches très réelles.
Le coût de la fin de vie. Au bout de 3 ans, vous reprenez tout à zéro : nouveau cycle d’achat, migration des données, réinstallation. Côté cloud, vous changez de génération d’instance en 5 minutes via 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 50 € par mois Salesforce par utilisateur, vous payez un service applicatif fini. Quand vous payez 700 € par mois une instance EC2, vous payez juste le droit d’utiliser une VM — il faut encore monter l’application, l’opérer, 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 (souvent 20 à 40 % du TCO trois ans), de formation des équipes (plusieurs mois de productivité dégradée), et de réversibilité future si vous voulez sortir.
L’illusion de la flexibilité. Le cloud promet la flexibilité, mais quand vous engagez des Reserved Instances 3 ans pour économiser 60 %, vous re-créez un CAPEX déguisé en OPEX, sans la propriété du matériel à la fin. Vous avez 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.
- Workloads variables avec un ratio creux/pic supérieur à 3.
- 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.