Hébergement local ou cloud : ce qu'on a vraiment appris en déployant à 5 €/mois
Le cloud est devenu un réflexe.
AWS, GCP, Azure… on y déploie vite, on scale facilement, on profite de services managés puissants, et dans beaucoup de cas, c'est exactement ce qu'il faut.
Mais doit-on pour autant forcément partir dans le cloud ? Est-ce qu'un service interne a toujours besoin d'une infrastructure managée ? Est-ce qu'on mesure vraiment ce que l'on consomme quand tout est abstrait derrière un dashboard ?
Pour en discuter, nous avons échangé avec Onur, ingénieur DevOps & Cloud, et Romain, Product Owner passionné par les sujets d'hébergement, qui a récemment déployé en local un outil utilisé en interne chez INOCO.
L'objectif n'était pas d'opposer local et cloud mais de partager à partir de nos expériences ce que ces deux approches changent concrètement : en matière de coûts, de souveraineté, de mise en œuvre, de disponibilité… et de responsabilité.
Héberger en local, ça veut dire quoi ?
Héberger en local ou on-premise consiste à faire tourner une application sur du matériel que l'on possède ou que l'on contrôle directement : un serveur, une machine dédiée, un mini-PC, voire un ordinateur déjà disponible dans l'entreprise.
À l'inverse, dans le cloud, l'infrastructure est louée auprès d'un fournisseur externe. On ne gère pas les machines physiques, on consomme des ressources à la demande : calcul, mémoire, stockage, réseau, services managés, bases de données, fonctions serverless, etc.
Sur le papier, le cloud semble plus simple. Et souvent, il l'est. Mais le local a quelques arguments solides, surtout lorsqu'on cherche à mieux comprendre ce que l'on consomme.
Pourquoi envisager un hébergement on-premise ?
La maîtrise des données : un enjeu politique autant que technique
La première raison : la maîtrise des données.
Peu importe la taille de l'entreprise ou l'ampleur du projet, quand les données sont stockées sur ses propres serveurs, l'entreprise garde physiquement la main dessus. Ce point peut devenir très important pour certains clients, certaines organisations ou certains secteurs sensibles.
« Tu as la main directement sur tes données, vu que tu les stockes sur tes serveurs à toi. Certaines entreprises veulent vraiment être rassurées en gardant complètement la main dessus. » — Onur
Même si les cloud providers proposent aujourd'hui de très hauts niveaux de sécurité, de certifications et de conformité, la question devient politique. Elle touche à la confiance, à la gouvernance et parfois à la culture de l'entreprise. On avait déjà exploré cette dimension sous l'angle réglementaire dans notre article sur le cloud de confiance et les enjeux SecNumCloud.
Des coûts plus lisibles, mais pas inexistants
L'autre sujet qui revient très vite, c'est le coût.
Dans le cloud, il est facile de lancer une instance, un environnement de test, un service temporaire… puis de l'oublier. Et comme rien n'est visible physiquement, la consommation peut continuer pendant des semaines sans que personne ne s'en rende compte.
Onur l'a vécu sur des projets : certaines instances étaient trop dimensionnées par rapport au besoin réel, et des serveurs de développement tournaient en continu alors qu'ils n'étaient utiles que sur les horaires de travail. En ajustant la taille des instances et en les éteignant automatiquement les soirs et week-ends, la facture a presque été divisée par deux.
« Ce n'est pas parce qu'on ne voit pas les ressources qu'on doit se permettre de faire n'importe quoi avec. Il y a un vrai impact derrière. » — Onur
En local, l'effet est différent. La ressource est finie. Si une application consomme trop de RAM, trop de CPU ou trop de stockage, on le ressent plus vite. On est obligé de composer avec ce que l'on a.
Romain le résume simplement : en local, la variable d'ajustement n'est pas uniquement le budget. Il faut faire rentrer le projet dans les ressources disponibles.
Cette contrainte peut devenir vertueuse. « Elle pousse à mieux dimensionner, à éteindre ce qui ne sert pas, à optimiser davantage, à éviter de surconsommer par défaut. » — Romain
L'hébergement local n'est pas gratuit. Il faut distinguer deux types de coûts.
D'un côté, le coût de départ : acheter ou récupérer une machine, prévoir éventuellement une salle adaptée, du réseau, une alimentation stable, un minimum de sécurité physique. Dans certains contextes, cela peut vite devenir conséquent.
Onur évoque par exemple son expérience au ministère de l'Intérieur, où l'installation de serveurs impliquait du matériel dédié, des racks, des interventions physiques, des systèmes à installer, puis de la maintenance à distance. Un serveur professionnel peut représenter plusieurs milliers d'euros d'investissement initial, sans compter la climatisation, la sécurité physique, l'aménagement de la salle ou le temps humain nécessaire.
De l'autre côté, une fois le matériel en place, le coût d'exploitation peut être faible : un peu d'électricité, de maintenance, et éventuellement quelques services complémentaires.
Romain et Onur le formulent donc comme un arbitrage : en local, on investit davantage au départ, mais le coût récurrent peut être très maîtrisé. Dans le cloud, on économise l'investissement initial, mais on paie la flexibilité à l'usage. Et cette flexibilité peut coûter cher si elle n'est pas surveillée.
Cloud ou on-premise : comment choisir selon son projet ?
Les deux approches ont du sens. La question est surtout : pour quel projet, avec quelles contraintes, quelles compétences et quel niveau de risque acceptable ?
Pour Onur, si une entreprise démarre sans infrastructure existante, le cloud reste souvent le choix le plus efficace. Il permet de gagner du temps, de profiter de services managés, de scaler facilement et d'éviter d'avoir à gérer le matériel.
« Le cloud te permet de mettre en production très vite. C'est managé, automatisé, et tu retrouves souvent les mêmes concepts d'un provider à l'autre. » — Onur
À l'inverse, si l'entreprise possède déjà du matériel, si le besoin est limité, ou si les données ne doivent pas sortir d'un périmètre maîtrisé, l'hébergement local peut devenir très pertinent.
Romain y voit aussi un gros intérêt pour certains projets qui démarrent. Sur un prototype, un outil interne ou une application de faible ampleur, le local peut permettre de limiter les coûts, d'éviter une dépendance trop rapide à un cloud provider et de garder une architecture plus transférable.
Car le cloud moderne ne se limite pas à "louer un serveur". Il propose tout un écosystème de services : fonctions serverless, bases managées, files de messages, outils de monitoring, IAM, pipelines, etc. C'est très puissant. Mais plus on s'appuie sur des services spécifiques, plus il peut devenir coûteux de changer de fournisseur ou de revenir vers du on-premise.
Romain prend l'exemple d'AWS Lambda : le service apporte de vrais bénéfices de scalabilité et d'automatisation, mais développer spécifiquement pour Lambda signifie aussi adapter son code à cet environnement. Si l'on veut sortir d'AWS un jour, il faudra probablement retravailler une partie de l'architecture.
Déployer un outil interne à 5 €/mois : notre cas concret
Chez INOCO, Romain a récemment travaillé sur le déploiement local du Deck, un outil interne destiné aux collaborateurs.
Le besoin initial : permettre aux consultants de consulter et mettre à jour leur profil, renseigner leurs compétences, leurs expériences, leurs parcours, et permettre aux chargés d'affaires de générer plus facilement des dossiers de compétences. L'objectif est de réduire le travail manuel.
Techniquement, le Deck repose sur un backend en C# .NET, un frontend Angular, et une instance N8N utilisée pour automatiser certaines étapes, notamment l'ingestion des CV.
Mais le plus intéressant ici, c'est l'infrastructure choisie.
Architecture hybride : Proxmox, Docker et VPS
Plutôt que de tout héberger sur AWS, GCP ou Azure, Romain a mis en place une approche hybride, entre on-premise et cloud "léger".
Côté local, l'application tourne sur une machine déjà disponible chez INOCO. Sur cette machine, Romain a installé Proxmox, une distribution basée sur Debian, spécialisée dans la virtualisation. Elle permet de créer et gérer des machines virtuelles ou des conteneurs Linux. Sur ces machines virtuelles, les applications sont ensuite déployées avec Docker.
Côté externe, INOCO utilise un VPS à environ 5 € par mois. Ce VPS ne porte pas l'application elle-même. Il sert de point d'entrée public pour accéder aux services hébergés localement.
Pourquoi ce choix ? Pour éviter d'exposer directement le réseau local de l'entreprise sur Internet.
Romain a mis en place un tunnel VPN chiffré entre l'infrastructure locale et le VPS, grâce à NetBird, une solution basée sur WireGuard. Le VPS devient ainsi la porte d'entrée publique, tandis que les applications restent hébergées dans le réseau local. Cette architecture permet de garder un niveau de sécurité raisonnable sans devoir monter une infrastructure complexe. Elle évite aussi à chaque collaborateur d'avoir besoin d'un VPN individuel pour accéder à l'outil.
Sécuriser avec Authentik et NetBird sans retarder le déploiement
Un autre point intéressant du déploiement concerne l'authentification.
Le Deck ne disposait pas encore d'un système d'authentification complet intégré dans le code. Développer proprement cette partie peut prendre du temps : gestion des utilisateurs, rôles, permissions, sessions, sécurité, etc.
Pour avancer sans bloquer l'usage interne, Romain a déployé Authentik en local, connecté au SSO Google de l'entreprise. NetBird permet ensuite d'appliquer cette couche d'authentification sur les routes exposées.
En pratique, lorsqu'un utilisateur tente d'accéder au Deck, il est d'abord redirigé vers l'authentification. Une fois connecté avec son compte Google INOCO, l'accès au service est autorisé.
Ce n'est pas forcément la solution définitive. Mais pour un usage interne, en phase de test ou de POC, cela permet d'obtenir rapidement un niveau de sécurité acceptable, sans retarder toute la mise à disposition de l'outil.
« En attendant de faire ça de façon plus permanente, on a une solution qui nous permet quand même de commencer à l'utiliser et à le tester. » — Romain
Pourquoi ce choix était pertinent pour ce projet
Le Deck est un bon candidat pour ce type d'hébergement, parce qu'il s'agit d'un outil interne, utilisé par une cinquantaine de collaborateurs, avec un niveau de criticité limité.
Si le service est indisponible quelques heures, l'impact reste maîtrisable. Ce n'est pas une plateforme client critique, ni un service utilisé 24h/24 par des milliers d'utilisateurs.
Le projet ne nécessitait pas non plus une scalabilité massive ou des services cloud avancés. Les ressources nécessaires restent modestes, et l'entreprise disposait déjà d'une machine pouvant accueillir l'application.
Résultat : l'investissement initial est presque nul, et le coût récurrent est très faible : environ 5 € par mois pour le VPS, plus quelques euros d'électricité.
À titre de comparaison, Romain évoque un autre projet interne, d'ampleur comparable, qui avait généré une facture AWS autour d'une centaine d'euros par mois pendant sa phase de développement. Cette facture aurait probablement pu être optimisée, mais le problème est justement là : tant qu'on ne regarde pas, le coût continue de tourner.
Avec le déploiement local du Deck, le coût est connu à l'avance. Il ne peut pas déraper silencieusement.
L'architecture actuelle répond au besoin. Mais elle pourrait évoluer. Si le service devenait plus critique, il serait possible d'investir quelques centaines d'euros dans plusieurs mini-PC pour créer un petit cluster, améliorer la disponibilité, ajouter un onduleur, renforcer les sauvegardes ou mieux structurer la supervision. L'intérêt de cette approche, c'est qu'elle peut grandir progressivement. On commence simple, on observe, puis on renforce là où c'est nécessaire.
Auto-héberger des outils open source : ça vaut le coup ?
Ce cas d'usage ouvre aussi une autre piste : l'auto-hébergement de solutions open source.
Certaines entreprises paient des abonnements mensuels pour des outils qui existent aussi en version open source. Ce modèle managé a de vrais avantages : simplicité, maintenance prise en charge, mises à jour, support, disponibilité.
Mais pour certains usages internes, peu critiques ou bien maîtrisés, il peut être intéressant de se demander si l'on peut héberger soi-même l'outil.
Chez INOCO, c'est déjà le cas avec N8N. L'outil est open source, et l'entreprise propose également une version managée payante. En l'hébergeant nous-mêmes, nous pouvons l'utiliser pour nos automatisations internes, sans augmenter le coût à chaque nouvel utilisateur.
Là encore, tout dépend du contexte. Payer pour une solution managée peut être le bon choix si l'on veut déléguer l'exploitation, réduire la charge interne et garantir un niveau de service. L'auto-hébergement prend davantage de sens quand le risque est limité, que l'équipe a les compétences nécessaires, et que la maîtrise des coûts ou des données devient prioritaire.
Ces arbitrages d'infrastructure font partie des sujets qu'on adresse régulièrement dans nos missions DevOps et Cloud.
Ce qu'on retient
Cette discussion nous a surtout rappelé qu'il n'y a pas de réponse universelle.
Le cloud reste extrêmement pertinent pour de nombreux projets. Il permet d'aller vite, de bénéficier de services puissants, d'automatiser beaucoup de choses et de réduire la complexité matérielle.
Mais l'hébergement local mérite d'être reconsidéré dans certains cas : outils internes, prototypes, projets modestes, données sensibles, besoin de coûts prévisibles, ou volonté de garder une architecture plus indépendante.
Chez INOCO, l'exemple du Deck montre qu'un déploiement local peut être simple, peu coûteux et suffisamment robuste pour un usage interne, à condition d'accepter ses limites et de les traiter progressivement.
Finalement, la question n'est pas "local ou cloud ?" La question est plutôt : de quoi avons-nous vraiment besoin, quelles contraintes sommes-nous prêts à porter, et quel niveau de maîtrise voulons-nous garder ? C'est souvent en partant de ces questions-là que l'on construit les choix d'infrastructure les plus adaptés.
