Le site Internet super-économique

Quentin Lagonotte — Tue, 15 Sep 2026 09:05:05 +0000

Un site Internet, c'est un super moyen de communication. Les cas d'usage sont infinis, tout le monde y a accès du bout des doigts en quelques secondes, et c'est classe. Mais ça coûte !

Je vous présente ici comment j'ai réduit le coût d'hébergement de mon site Internet au maximum, dans le cadre de mon association, BROCCONOTTE, qui avait pour but d'effectuer un raid humanitaire au Maroc.

Mes besoins simples

Pour le contexte, mes besoins étaient très simples : je devais communiquer auprès de mes sponsors de manière professionnelle.

Il me fallait donc des sites Internet, "bien faits" en apparence, disponibles 24h/24, mais avec assez peu de fréquentation. On parle de quelques dizaines de sponsors, qui consultent les informations relativement peu souvent.

Mes cas d'usage étaient les suivants : présenter un contenu fixe (l'association, l'équipe et le projet), afficher une position en direct sur une carte, et enfin, récupérer des informations de contact d'abonnés à une newsletter (leurs e-mails).

Le tout avec un credo absolu : dépenser l'extrême minimum d'argent.

J'ai donc creusé et trouvé des solutions super-économiques, que je vous partage ici.

Mon but est de rendre cet article accessible à tout public, y compris aux moins techniques : pour cela, je vais aborder des concepts d'hébergement de site Internet le plus simplement possible.

Les Internet Content Management Systems

La manière la plus simple de se faire un site Internet avec peu de connaissances, c'est d'utiliser des produits spécialisés qui proposent des offres sur étagère. On peut citer WordPress, Wix, Canvas ou Internetador. Au moment où je consulte les tarifs de WordPress, l'offre de base est à 4 € par mois, soit 48 € par an pour un seul site (ce qui me semble être une offre plutôt avantageuse par rapport aux concurrents).

C'est une solution peu permissive en termes de fonction, et surtout, c'est un coût que je juge trop important !

Coder soi-même

L'alternative, c'est de coder mon propre site Internet. J'ai un peu d'expérience, je connais le HTML / CSS et le JavaScript, et l'IA peut être un bon accélérateur.

Sauf qu'il faut héberger ce site, et là encore le coût est important.
Exemple, chez OVH, il y a une offre à ~2 € par mois, soit 24 € par an. C'est encore trop pour moi !

Je pourrais également héberger ma propre infrastructure, mais alors, il faut investir dans du matériel et prévoir le coût électrique associé. Ça ne m'intéresse pas.

Je vais donc fouiller et trouver les meilleures opportunités pour me faire mon infrastructure de site à moindre coût.

L'infrastructure

La mise en ligne du site

La première chose, c'est de trouver un hébergement capable d'exposer le contenu de mon site Internet, donc mon code, à des visiteurs.

En termes de technologie, je code une interface ultra-simple en HTML, CSS et JavaScript. Il serait tout à fait possible d'utiliser des bibliothèques comme React, Vue ou Angular, mais moi, je reste simple.

Mon premier objectif, c'est de présenter mon projet et mon association. À ce stade, l'intégralité du contenu est donc directement dans le code.

Une fois mon site réalisé, codé et testé localement, je peux le déposer sur GitHub.

GitHub

GitHub, c'est un outil de gestion de développement logiciel gratuit, bien connu des développeurs.

Pour faire simple, il me permet de stocker mes fichiers de code dans un dépôt, appelé "repository" dans GitHub, et de conserver l'historique des évolutions. Si un jour, par exemple, je fais une modification qui casse complètement mon site, je peux revenir facilement à une version précédente qui fonctionnait.

Procédure :

- Je vais sur le site https://github.com/ en étant connecté à mon compte (gratuit)
- Je crée un nouveau "repository" avec une visibilité "publique" (important pour la suite)
- Je pousse mon code sur ce répertoire

Mon code est donc hébergé. Il faut maintenant l'exposer, c'est-à-dire le rendre visible par tous sur Internet. Pour ça, j'utilise une fonctionnalité de GitHub : GitHub Pages.

GitHub Pages

GitHub Pages permet nativement et gratuitement d'exposer mon code.

Concrètement, GitHub Pages va définir une URL accessible depuis n'importe quel navigateur sur Internet, et exécuter le fichier principal du site, généralement index.html, à partir de mon dépôt GitHub.

Procédure :

- Sur GitHub, dans les paramètres du "repository" ("Settings")
- Dans la section "Code and automation", puis "Pages"
- Je sélectionne la branche "main" comme branche à exposer
- Je choisis entre "root (/)" ou "docs (/docs)" pour indiquer dans quel dossier se situe ma page HTML principale (index.html)

Première victoire : mon site est en ligne, visible sur Internet, et je n'ai pas dépensé un seul centime.

Mais j'ai un soucis. L'URL du site est définie par GitHub : https://quentin1500.github.io/newsletter-brocconotte. Ça révèle la solution gratuite, ça ne fait pas suffisament professionnel : en terme de communication, on peut faire mieux.

Ajustement de l'URL

Obtenir un domaine

Sur GitHub Pages, j'ai la capacité de configurer un domaine personnalisé. C'est exactement ce qu'il me faut.

Un domaine, c'est l'usage d'un nom unique sur Internet, basé sur une étiquette et une extension.

Exemples :

google.com
wikipedia.org
mon-domaine.fr

Cela va donc me permettre d'utiliser un domaine au nom de mon association, qui me servira d'URL et masquera celle de GitHub.

Pour acquérir un domaine, il faut passer par des hébergeurs. Il va falloir lâcher quelques deniers… Ce sera le prix à payer pour maximiser ma communication, alors j'essaye d'optimiser ça au maximum.

Chaque nom de domaine a un prix différent, et certaines extensions sont plus chères que d'autres. J'ai remarqué qu'en général les .fr sont moins chères que les .com.

Il y a une multitude de combinaisons, de bons plans, etc. Il va falloir faire des choix et des essais pour économiser un maximum.

association-brocconotte.com
brocconotte-asso.org
the-brocconotte.net

Les hébergeurs proposent des simulateurs pour découvrir le prix d'un nom de domaine.

Il existe beaucoup d'hébergeurs, donc je préfère m'orienter vers des plateformes reconnues, en vérifiant bien leur capacité à gérer les "sous-domaines" et les "résolutions DNS". J'en aurai besoin un peu plus tard.

J'ai opté pour IONOS, qui me semble adapté et surtout peu cher. Mais il existe plein d'alternatives possibles : Hostinger, OVHcloud, Nom-domaine.fr, etc. J'ai trouvé une offre à 1,20 € pour 1 an, pour un nom de domaine parfait : brocconotte.fr.

Configuration de mon domaine

Maintenant richement propriétaire de mon domaine, je vais pouvoir me créer un sous-domaine dédié à l'exposition de mon site.

Un sous-domaine est comme une portion de mon domaine. C'est un bon moyen de multiplier les URL disponibles, et donc d'avoir autant de sites que je le souhaite, sans surcoût. Je n'utilise donc pas directement mon domaine brocconotte.fr mais un sous-domaine que je vais définir.

Exemples de sous-domaines :

drive.google.com
mail.google.com
fr.wikipedia.org
mon-site.brocconotte.fr

Je crée donc le sous-domaine sous lequel sera exposé mon site : newsletter.brocconotte.fr

Je retourne sur GitHub, pour configurer ce domaine personnalisé dans mes Pages.

Je dois maintenant configurer le DNS de mon sous-domaine.

DNS

Le DNS, c'est ce qui permet à un navigateur de savoir vers quel serveur aller chercher le code, et donc d'afficher le bon site Internet. On pourrait y mettre une adresse IP, par exemple, ou, dans mon cas, un autre site.

Procédure :

- Sur mon hébergeur de domaine, je configure le DNS de mon sous-domaine
- Type CNAME (il en existe d'autres, mais c'est celui qui m'intéresse)
- Valeur : l'URL du GitHub Pages
    - quentin1500.github.io

Après quelques minutes d'attente, c'est bon : mon site 'https://newsletter.brocconotte.fr' est accessible partout sur Internet au travers de mon domaine, et pour vraiment pas cher !

Gestion de données

Mais, pour l'instant, mon site ne contient que des informations statiques, rédigées directement dans le code. Or, désormais, je veux aussi récupérer des informations provenant d'une source de données externe, en l'occurrence pour afficher une position sur une carte en temps réel.

La persistance de données

Le principe, c'est de stocker les données utilisées par mon site sur un système dédié.

Dans mon cas, ces données sont des positions GPS, qui me permettent d'afficher ma localisation en temps réel. Elles sont mises à jour régulièrement, toutes les minutes, par une application sur mon smartphone. Comme elles changent trop souvent, GitHub ne convient pas, contrairement à mon code, qui lui évolue peu.

En temps normal, on utiliserait une base de données. Mais même si certaines sont gratuites, comme MySQL ou PostgreSQL, leur hébergement, lui, coûte. Et vous connaissez ma politique à propos de ce qui a un coût…

J'ai décidé d'utiliser un outil bien connu de tous : Google Sheets.

Cela me permet de stocker mes données dans un tableur (comme Excel), de manière ordonnée, et surtout gratuitement, dans la limite des 20 Go offerts par Google Drive.

Procédure :

- Je vais sur https://drive.google.com/ (connecté à mon compte Google)
- Je crée un nouveau fichier Google Sheets
- Je renomme l'onglet par défaut (en bas) "positions"
- Je complète les en-têtes des colonnes "timestamp | lat | lng | accuracy | battery | device"

Maintenant que je sais où stocker ces données, il faut que je fasse le lien avec mon site.

Interface de programmation

Pour faire le lien entre mes données et mon site Internet, j'utilise un autre outil de l'écosystème Google : Apps Script.

Disponible dans le menu "Extensions" de Google Sheets, Apps Script va me permettre de créer une API personnalisée, capable de lire et d'alimenter mon fichier Google Sheets, et donc de permettre à mon site d'accéder à mes données stockées, gratuitement.

Une API, ou interface de programmation, c'est simplement le tunnel qui permet à deux applications de communiquer. D'un côté, j'ai le site qui s'exécute dans le navigateur ; de l'autre, j'ai mon fichier Google Sheets avec mes données.

Apps Script permet de coder dans un langage proche de JavaScript, et c'est typiquement prévu pour créer une interface entre le Internet et l'écosystème Google Drive. C'est parfait, et c'est gratuit.
Ici, l'intelligence artificielle est un bon allié pour m'accompagner dans le développement de cette interface.

Des fonctions utiles que j'ai utilisées :

function doGet(e) {...}        -> déclenchée par une requête GET, typiquement pour lire les données
function doPost(e) {...}       -> déclenchée par une requête POST, typiquement pour modifier / créer des données
function getSheet() {          -> récupération du contenu de la page du tableur
  const spreadsheetId = PropertiesService.getScriptProperties().getProperty('SHEET_ID');
  const sheet = SpreadsheetApp.openById(spreadsheetId).getSheetByName(SHEET_NAME);
  return sheet;
}

Une fois déployée, l'application fournit une URL que mon site peut appeler :

https://script.google.com/macros/library/d/APPS_SCRIPT_ID/1

Ici, pas de nom de domaine personnalisé, mais ce n'est pas important : ce ne sera pas visible à l'usage du site Internet.

Mon site est désormais capable de récupérer et afficher des données stockées sur un système dédié. La position de ma voiture est donc affichable en temps réel !

Mécanisme de protection des données

Pour un autre usage, une problématique apparaît : l'accès à mes données. Que tout le monde voit les données n'est pas gênant (dans ce cas), mais je veux être le seul à pouvoir les modifier. Il faut donc mettre en place un mécanisme de protection.

Le contenu de mon site n'est pas critique, donc je fais au plus simple, au moins cher, et donc pas forcément au plus sécurisé. Mais ça me convient.

Dans Apps Script, je code une fonction de vérification de mot de passe, que j'applique systématiquement à chaque modification ou création de données. Elle compare simplement le mot de passe envoyé dans la requête API à celui que je stocke dans un attribut privé d'Apps Script.

function verifyPassword(password) {
  const stored = PropertiesService.getScriptProperties().getProperty('ADMIN_PASSWORD');
  return password === stored;
           ↑             ↑
(mdp de la requête) (mdp stocké dans Apps Script)

}

Côté interface utilisateur, sur le navigateur, un mot de passe est demandé pour accéder à une interface d'administration. Pour vérifier qu'il est correct, le code compare la valeur saisie à une valeur stockée. Cette valeur stockée est chiffrée pour éviter qu'elle ne soit récupérée et utilisée.

Cette valeur chiffrée peut néanmoins, en théorie, être "brute-forcée", c'est-à-dire qu'un utilisateur malveillant pourrait comparer cette valeur avec des valeurs déjà calculées pour retrouver le véritable mot de passe.

Valeur chiffrée	Valeur préalablement calculée
f54dff746357502db7e8fa684e79f5f6ac063f65736077fe412e661a807cf43a	`Azerty`
73d5b2f4ba82d59c723c16a909524559d8f31e33c5d8fdcfc57065dca5c9f189	`Qwerty`
ef797c8118f02dfb649607dd5d3f8c7623048c9c063d532cc95c5ed7a898a64f	`12345678`

Mais, encore une fois, c'est un risque que j'accepte, car mon site et ses données ne sont pas critiques.

Finalement, c'est tout : mon site est sur Internet, sur un domaine à mon nom, et il persiste ses données de manière (relativement) sécurisée, le tout avec une dépense d'argent super limité.

Synthèse

Architecture globale

Pour récapituler, voilà l'architecture globale de mon site Internet :

Bilan financier

Voici le bilan financier de l'exposition de mon site pour 1 an :

Poste	Solution	Coût
Serveur d'hébergement Internet	GitHub Pages	00.00 €
Persistance des données	Google Sheets	00.00 €
Interface de programmation (API)	Google Apps Script	00.00 €
Nom de domaine	IONOS	01.20 €
TOTAL		01.20 €

Pas mal…

J'ai divisé la facture par 20 comparé à un hébergement sur OVH et encore 2 fois plus comparé à une solution comme WordPress (soldes de 97.5% !). Et surtout, 1,20 € par an, c'est négligeable dans mon fonctionnement associatif.

À noter que je peux me créer autant de sites Internet que je veux pour ce prix, en découpant mon domaine en plusieurs sous-domaines.

Les limites

Bien sûr, cette réduction de moyens limite ce que je peux implémenter et le niveau de sécurisation associé.

Limites de stockage

Les données que je stocke restent limitées par l'offre gratuite de Google Drive, soit 20 Go, ce qui est déjà très confortable. Je suppose aussi que Google limite l'usage des API Apps Script si le site est trop sollicité, ce qui pourrait se traduire par des chargements de pages plus lents.

Limites de sécurité

Mon mot de passe reste vulnérable, car il n'est protégé que par un chiffrement théoriquement cassable.

Limites de confidentialité

Enfin, mon code est public sur GitHub, donc non confidentiel : tout le monde peut le récupérer.

Pour toutes ces raisons, et dans ces conditions, on ne peut donc pas implémenter de site Internet avec des fonctions complexes :

On exclut une exposition à d'énormes volumes de données ou de consommation : le site va ramer et potentiellement atteindre des limites qui le casseront
On exclut l'usage de données critiques : fuite de données
On exclut la gestion de comptes utilisateurs : fuite de données liées à des usagers

Conclusion

Pour un besoin simple, peu d'affluence, des données peu sensibles, et avec une forte contrainte de budget, cette architecture est plutôt efficace. En combinant GitHub Pages, un nom de domaine peu cher, Google Sheets et Apps Script, on obtient un site visible sur Internet, personnalisable, capable de gérer de la données, pour un coût presque nul et d'une qualité presque professionnelle.

Évidemment, ce n'est pas une solution universelle. Dès qu'on a besoin de sécurité forte, de confidentialité, de volumétrie importante, on atteint vite ses limites. Mais pour un projet associatif, personnel, vitrine ou expérimental, c'est une très bonne solution : simple, efficace, et surtout super-économique.

DEV Community: Quentin Lagonotte

Le site Internet super-économique

Mes besoins simples

Les Internet Content Management Systems

Coder soi-même

L'infrastructure

La mise en ligne du site

GitHub

GitHub Pages

Ajustement de l'URL

Obtenir un domaine

Configuration de mon domaine

DNS

Gestion de données

La persistance de données

Interface de programmation

Mécanisme de protection des données

Synthèse

Architecture globale

Bilan financier

Les limites

Limites de stockage

Limites de sécurité

Limites de confidentialité

Conclusion