Imaginez un QR imprimé sur une carte de restaurant : il permet d’ouvrir le menu sur un téléphone. Si le restaurant quitte le service qui a créé le QR, pourra-t-il garder ses cartes ? Oui, à condition que le lien contenu dans le QR continue à ouvrir le menu.
L’auto-hébergement consiste à installer et à gérer soi-même un logiciel, au lieu d’utiliser celui d’un service en ligne. Pour les QR codes, on peut ainsi fabriquer les images, ou gérer les liens qu’elles ouvrent. Pour comprendre la différence, suivons le parcours d’un client qui consulte le menu.
Que se passe-t-il quand on scanne le QR ?
Dans notre exemple, le QR contient une adresse web. Le téléphone lit cette adresse, puis l’ouvre. Deux parcours sont possibles.
Le QR mène directement au site du restaurant. Il contient par exemple https://restaurant.example/menu. Le téléphone ouvre cette page. Le logiciel qui a dessiné le QR n’intervient plus : une fois l’image enregistrée, il n’a pas besoin de rester disponible.
Le QR passe d’abord par un service de liens. Il contient une adresse fournie par ce service, qui envoie ensuite le visiteur vers le menu. Cet envoi automatique vers une autre page s’appelle une redirection. Le service doit donc continuer à fonctionner pour que le client arrive au menu.
Votre site doit rester accessible.
Le service de liens doit aussi rester accessible.
C’est ce détour qui permet aux QR codes dits dynamiques de changer de destination : le service peut envoyer le prochain visiteur vers un autre menu. Le dessin du QR reste identique ; seule la page vers laquelle le service l’envoie change.
Si le QR ouvre directement votre site, vous pouvez aussi mettre à jour le contenu de la page tout en gardant son adresse. Changer les plats sur restaurant.example/menu ne demande pas de refaire le QR.
Créer le QR soi-même : ce que cela change
Un logiciel installé sur votre ordinateur peut fabriquer l’image à partir du lien que vous lui donnez. Vous gardez le fichier et pouvez l’imprimer. Pour cette seule opération, vous n’avez pas besoin de faire fonctionner un service en permanence sur Internet.
Nous l’avons vérifié en créant trois QR sans connexion réseau pendant leur fabrication. Les trois images contenaient bien les liens prévus. Cela ne rend pas les pages accessibles hors ligne : le client a toujours besoin d’une connexion pour consulter un menu sur le web.
Vous pouvez aussi installer un générateur sur un serveur, c’est-à-dire un ordinateur accessible à distance, pour que votre équipe l’utilise. Vous gérez alors son installation et ses accès.
Dans les deux cas, c’est le lien choisi qui détermine de qui vous dépendez. Fabriquer vous-même un QR contenant l’adresse d’un prestataire ne vous donne pas le contrôle de cette adresse. À l’inverse, un générateur en ligne peut créer un QR qui mène directement à votre propre site.
Le point décisif : à qui appartient le lien ?
Reprenons le restaurant. Si le QR contient une adresse appartenant au prestataire, le restaurant ne peut pas décider seul de la faire fonctionner ailleurs. Récupérer l’image ou la liste des menus ne lui transfère pas cette adresse.
Il existe une autre possibilité : utiliser une adresse du restaurant, même si un prestataire gère les liens pour lui. Le nom de domaine est la partie qui identifie le site, par exemple restaurant.example. Il peut être enregistré au nom du restaurant, avec des accès que celui-ci conserve.
Dans ce cas, il devient possible de confier le service à un autre hébergeur, sous réserve de pouvoir reprendre les liens. Un hébergeur est l’entreprise qui met à disposition l’ordinateur sur lequel le service fonctionne. Avoir son domaine et tout gérer soi-même sont donc deux choix différents.
Le QR imprimé garde toujours l’adresse d’origine. Si elle se termine par /menu, il faut que cette adresse exacte fonctionne après le changement. Recréer une page à une autre adresse ne modifie pas les cartes déjà distribuées.
Comment garder les QR en changeant de service ?
Il faut conserver l’adresse lue par le téléphone et pouvoir lui faire ouvrir la bonne page. Si vous utilisez des redirections, le nouveau service doit donc récupérer la liste qui indique où chaque lien doit envoyer le visiteur. Par exemple : « le lien du menu ouvre cette page ; le lien de contact ouvre celle-ci ».
Pour tester ce mécanisme, nous avons créé trois QR. Nous avons arrêté le petit service qui gérait leurs liens, puis lancé son remplaçant. Au départ, celui-ci ne connaissait aucun des liens : les pages étaient introuvables. Après avoir chargé la copie de la liste, les trois liens fonctionnaient à nouveau. Nous avons ensuite changé la page associée à l’un d’eux, sans modifier son image QR.
Le test montre l’utilité de cette sauvegarde. Il a été réalisé sur un seul ordinateur, sans transfert d’un vrai site public ni scan sur téléphone. Les étapes et les fichiers sont disponibles dans les sources. Un déménagement réel demande aussi de faire arriver les visiteurs au nouveau serveur et d’y rétablir la connexion sécurisée HTTPS.
Avant de choisir un prestataire, vérifiez donc que vous pouvez récupérer vos liens et les réutiliser ailleurs. Un bouton « exporter » ne suffit pas à le garantir : il faut savoir ce que contient le fichier et essayer de le reprendre dans le service de remplacement.
Qu’est-ce qu’il faut entretenir soi-même ?
Si vous gérez vous-même le service de liens, quelqu’un doit s’occuper de son fonctionnement. Le logiciel doit rester disponible quand les clients scannent les QR. Cela demande notamment de :
- renouveler le nom de domaine pour garder l’adresse ;
- faire les mises à jour et protéger l’accès à l’administration ;
- sauvegarder la liste des liens et vérifier qu’on sait la récupérer après une panne ;
- surveiller les erreurs et intervenir quand le service s’arrête.
Des logiciels comme Shlink servent à gérer ces liens. Leur installation ne dispense pas de l’entretien. Nous avons consulté la documentation de Shlink, sans installer ni tester ce logiciel ; les précisions techniques sont regroupées dans les sources.
Si vous souhaitez aussi garder l’historique des scans, vérifiez sa sauvegarde séparément. Rétablir les liens ne signifie pas que les anciennes statistiques seront récupérées.
Quel choix pour vous ?
Vous avez seulement besoin d’un QR vers votre site. Une image contenant directement l’adresse de votre page peut suffire. Vous pouvez la créer avec un outil local ou un générateur gratuit. Gardez la page disponible à cette adresse.
Vous voulez pouvoir changer la page ouverte après le scan. Un service de liens peut s’en charger. Si vous souhaitez pouvoir en changer plus tard, cherchez une offre qui accepte votre propre domaine et dont vous avez vérifié la reprise des liens. Vous pouvez déléguer l’exploitation tout en conservant votre adresse.
Vous voulez administrer vous-même le service. L’auto-hébergement est une option si une personne sait l’installer, l’entretenir et réparer une panne. Son temps de travail fait partie du coût. Notre comparatif des tarifs présente les offres hébergées ; il ne chiffre pas cette maintenance pour vous.
Avant d’imprimer beaucoup de supports, faites l’essai avec un QR. Vérifiez le lien contenu dans l’image, puis ce qu’il faudra conserver si vous quittez le service. C’est plus simple à régler avant de distribuer les cartes du restaurant.
Sources et détails techniques du test
Le test a été réalisé le 3 novembre 2026 avec trois liens : /menu, /guide et /contact.
| Étape | Résultat observé |
|---|---|
| Service initial en marche | Trois redirections HTTP 302, puis trois réponses de destination 200. |
| Service initial arrêté | Connexion refusée sur cette instance. |
| Service de remplacement, base vide | Trois erreurs 404 : les liens sont inconnus. |
| Sauvegarde restaurée, mêmes noms d’hôte et chemins | Les trois liens retrouvent leur destination. |
Destination de /menu modifiée | Le même QR conduit à la nouvelle page. |
| Liens recréés sous un autre nom d’hôte | Les trois anciennes adresses répondent 404 ; la nouvelle adresse de contrôle fonctionne. |
Les images PNG sont restées identiques, octet pour octet. Apple Vision les a décodées avant et après l’essai. Le client envoyait les requêtes explicitement au serveur local, avec le nom d’hôte demandé. Deux instances successives sur le même Mac utilisaient des bases SQLite séparées. Aucun DNS public, certificat HTTPS, cache navigateur, logiciel Shlink ou scan physique n’a été testé.
- Résultats complets, script reproductible et décodeur Apple Vision. Le script utilise le serveur HTTP de Python, déconseillé en production. Ce test ne mesure ni performances, ni disponibilité à long terme, ni supériorité d’un logiciel.
- Segno, documentation officielle : bibliothèque de génération PNG/SVG. Version utilisée : 1.6.1, avec les connexions réseau du processus Python bloquées pendant la génération.
- IETF, RFC 9110, origines HTTP et réponse 302. Les redirections du test utilisaient
Cache-Control: no-store. Les domaines.testet.examplesont réservés par la RFC 2606 ; les adresses d’exemple ne sont pas des sites à visiter. - Shlink, documentation : gestion de liens par API ou ligne de commande, avec un client web séparé. Les consignes de persistance Docker réservent la base SQLite intégrée aux essais et demandent une base externe pour la production.
- Import Shlink : le CSV exige le code court et l’URL longue, avec un domaine facultatif ; l’import direct depuis une autre instance exige que la source reste accessible. Cette migration ne remplace pas une sauvegarde indépendante. Configuration HTTPS par reverse proxy : le certificat reste à configurer. Documentation consultée le 3 novembre 2026.
Partager cet article