Modifier son site soi-même : le CMS basé sur Git

L’objection la plus fréquente face à un site statique : « C’est rapide, d’accord. Mais si je veux changer un prix ou ajouter une photo, il faudra vous appeler à chaque fois ? »

Non. Et si un prestataire vous répond autrement, posez-vous des questions : un site que le propriétaire ne peut pas modifier est un site qui se périme, ou qui génère une facture à chaque virgule.

Voici comment ça marche réellement, et ce que vous pouvez ou non faire vous-même.

Le principe

Sur un site WordPress classique, votre contenu vit dans une base de données. Vous vous connectez à une interface d’administration, vous modifiez, c’est enregistré en base, et la page est reconstruite à chaque visite.

Sur un site statique avec CMS Git, le contenu vit dans des fichiers texte rangés dans votre dépôt de code. Vous vous connectez à une interface d’édition, vous modifiez, et l’outil enregistre la modification dans ces fichiers. Le site se reconstruit automatiquement et se redéploie, en général en une à deux minutes.

De votre côté, l’expérience est comparable à WordPress : des champs, du texte, un bouton « enregistrer ». La différence est ce qui se passe derrière — et elle a des conséquences très concrètes.

Ce que ça change pour vous

Aucun abonnement. Pages CMS et Decap sont gratuits. Pas de coût par utilisateur, pas de palier à franchir quand votre contenu grossit.

Un historique complet et gratuit. Chaque modification est enregistrée avec sa date et son auteur. Vous pouvez voir exactement ce qui a changé et revenir à n’importe quelle version antérieure. Sur WordPress, cette fonctionnalité passe souvent par une extension payante.

Un site qui reste rapide. Modifier le contenu ne ralentit pas le site, parce qu’il n’y a pas de base de données interrogée à chaque visite. Votre site reste aussi rapide au bout de trois ans et deux cents articles qu’au premier jour.

Rien à maintenir. Pas de mises à jour de sécurité mensuelles, pas d’extensions à surveiller. Le risque de voir le site piraté parce qu’une extension n’a pas été mise à jour disparaît.

Le contenu vous appartient physiquement. Vos textes sont des fichiers lisibles dans votre dépôt. Si vous changez de prestataire, vous partez avec. C’est un vrai sujet : les litiges autour de l’accès au site sont fréquents.

Ce que vous pouvez modifier vous-même

C’est le point que je détaille toujours en début de projet, parce qu’il détermine votre autonomie réelle.

Les champs sont définis à l’avance, un par un. Concrètement, pour un site vitrine, cela couvre en général :

• Tous les textes des pages : titres, paragraphes, boutons
• Les coordonnées : téléphone, e-mail, adresse, horaires
• Les photos et images
• Les articles de blog : création, modification, suppression
• Les services, tarifs, membres de l’équipe, questions fréquentes
• Les titres et descriptions qui apparaissent dans Google

Ce que vous ne pouvez pas faire : déplacer des blocs, changer les couleurs, modifier la structure d’une page. C’est volontaire. Le CMS expose des champs, pas un constructeur de pages libre. Vous ne pouvez pas casser la mise en page par accident — ce qui est la première cause de sites devenus incohérents après six mois d’édition par un constructeur visuel.

C’est un arbitrage : moins de liberté, beaucoup moins de risque. Pour la plupart des entreprises, c’est le bon compromis. Si vous voulez réellement recomposer vos pages librement, dites-le au départ, ça change le choix d’outil.

Une session d’édition typique

1. Vous ouvrez l’interface et vous vous connectez avec votre compte GitHub.
2. Vous choisissez ce que vous voulez modifier — par exemple « Textes du site » puis « Accueil », ou « Blog » puis « Nouvel article ».
3. Vous modifiez les champs concernés.
4. Vous enregistrez.
5. Une à deux minutes plus tard, le site en ligne est à jour.

Le délai de reconstruction surprend parfois au début : sur WordPress, la modification est visible instantanément. Ici, le site est régénéré puis redéployé. En contrepartie, le visiteur reçoit un fichier déjà prêt, servi depuis un réseau de diffusion — d’où la rapidité.

Les limites, honnêtement

Il faut un compte GitHub. C’est gratuit et ça prend deux minutes, mais c’est une étape inhabituelle pour un gérant de PME. Je la fais avec le client au moment de la livraison.

L’interface est en anglais sur la plupart de ces outils. En revanche, les champs eux-mêmes sont nommés dans la langue que le développeur choisit — je les libelle systématiquement en français.

Un champ non déclaré est un champ invisible. Si le développeur oublie de déclarer un texte dans la configuration, vous ne pourrez pas le modifier, sans message d’erreur pour vous l’indiquer. C’est le piège principal de ce type d’outil, et j’ai fait l’erreur sur ce site même : une cinquantaine de textes étaient inaccessibles depuis l’interface jusqu’à ce que je vérifie champ par champ. Demandez à votre prestataire de contrôler que tous les textes sont bien exposés.

L’édition simultanée est mal gérée. Si deux personnes modifient le même fichier en même temps, il peut y avoir un conflit. Pour une équipe de un à trois éditeurs, c’est un non-sujet. Au-delà, un CMS hébergé comme Sanity est plus adapté.

Est-ce le bon choix pour vous ?

Oui, si vous modifiez votre contenu occasionnellement — quelques fois par mois — vous êtes une ou deux personnes à le faire, et vous voulez éviter tout abonnement.

Non, si vous publiez plusieurs fois par jour avec une équipe éditoriale, avec relecture et validation avant publication. Dans ce cas, un CMS hébergé fait mieux le travail et le surcoût se justifie.

Pour l’immense majorité des sites vitrines, de cabinets et de PME au Maroc, la première situation est la bonne. Ce site fonctionne exactement ainsi.

Une question sur votre cas précis ? Écrivez-moi, je réponds sous 24 heures.

---

Voir aussi : la page site vitrine pour voir ce que donne un site simple, sans dépendance technique.