On a vu un TTFB passer de 180 ms à 1,1 s sur une fiche produit après une mise en production anodine. Aucun changement de code, aucune montée en charge. Juste un paramètre gzip off dans le nginx.conf de production, alors que la recette validait tout avec gzip on. Le fichier avait été modifié à la main en prod six mois plus tôt pour débugger un problème de compression sur des fichiers binaires, jamais reporté sur l’environnement de test. Résultat : des Core Web Vitals dégradés pendant trois jours, le temps que quelqu’un rouvre le fichier de configuration et se souvienne.
La synchronisation de fichiers de configuration n’est pas un détail ops. Elle conditionne la reproductibilité des mesures de performance et la stabilité des métriques que Google regarde. Et si vous gérez plusieurs machines, plusieurs environnements, ou même plusieurs développeurs qui touchent aux réglages serveur, l’outil qui verrouille cette cohérence s’appelle Unison.
Le TTFB qui a doublé à cause d’un fichier non synchronisé
Quand on parle de Core Web Vitals, l’attention se porte sur le JS, le poids des images, la priorité de chargement. La configuration du serveur HTTP reste dans l’angle mort. Pourtant, c’est elle qui dicte la compression, la mise en cache, les en-têtes de sécurité, la négociation HTTP/2 ou HTTP/3, et au final le temps de réponse du premier octet.
Un TTFB élevé allonge mécaniquement le LCP. Sur un site e-commerce en Next.js avec des pages produit rendues côté serveur, un écart de 800 ms sur le TTFB se répercute directement sur le délai d’affichage du contenu principal. Si la configuration de compression diverge entre le staging et la production, toutes les mesures faites en recette deviennent non représentatives. Vous validez un TTFB à 200 ms en staging et le vrai trafic subit une seconde complète en plus.
Le problème est aggravé quand plusieurs personnes ajustent les fichiers de configuration en parallèle. Un développeur active Brotli sur la staging pour tester un gain. Un ops désactive le cache des fichiers statiques en production pour un hotfix. Les deux modifications ne sont jamais réconciliées. La divergence s’installe, silencieuse.
C’est un enjeu de fiabilité de l’analyse de performance. Sans une synchronisation garantie des paramètres serveur, chaque itération sur les Core Web Vitals est biaisée. La bonne nouvelle, c’est qu’il existe un outil taillé pour ce problème de synchronisation bidirectionnelle avec gestion des conflits.
Pourquoi rsync ne suffit pas quand on synchronise dans les deux sens
Beaucoup d’équipes utilisent rsync pour copier des fichiers d’un serveur à l’autre. Le flux est unidirectionnel : une source écrase une destination. Si vous modifiez un paramètre à la fois sur la source et sur la destination, le dernier rsync écrase l’une des deux versions sans poser de question. En environnement de production, ce comportement est dangereux.
Unison fonctionne sur un modèle bidirectionnel. Il compare les deux répertoires et propage les modifications dans les deux sens, en détectant les conflits. Vous pouvez modifier le fichier nginx.conf sur la machine de staging et, dans la même journée, ajuster un paramètre de keepalive_timeout directement sur le serveur de production parce qu’un pic de trafic l’exigeait. Unison repère que les deux versions ont divergé et ne choisit pas à votre place. Il vous demande de résoudre le conflit, ou applique une règle que vous avez définie à l’avance.
Unison conserve une archive de synchronisation qui enregistre l’état des fichiers après chaque opération. Cela lui permet de suivre les changements sans se reposer uniquement sur les timestamps. Même après une interruption réseau ou un redémarrage, il sait quelle version est la plus récente selon l’historique de synchronisation, pas selon l’horloge de la machine qui peut dériver.
⚠️ Attention : Ne lancez jamais un profil Unison en production sans l’avoir testé sur des répertoires jetables. Une règle
forcemal configurée peut propager une version erronée sur tous les nœuds en une seule commande.
La détection de conflits : un filet de sécurité quand tout est modifié en même temps
Unison ne fusionne pas le contenu des fichiers, il détecte juste qu’un même fichier a changé des deux côtés depuis la dernière synchronisation. Il signale le conflit et propose de le résoudre manuellement ou par une règle prefer. Cette granularité évite qu’une modification de dernière minute en production ne soit bêtement écrasée par la version de staging.
Monter un profil Unison pour votre parc de configurations serveur
On va tutoyer pour cette partie, parce qu’on va poser les mains dans le terminal.
Crée un fichier de profil conf-servers.prf dans ~/.unison/. Voici une base solide pour synchroniser le dossier /etc/nginx/conf.d/ entre ta machine de référence et deux serveurs web.
root = /etc/nginx/conf.d
root = ssh://user@web1//etc/nginx/conf.d
prefer = newer
times = true
perms = 0
group = true
owner = true
ignore = Name *.swp
ignore = Name .DS_Store
batch = false
auto = trueLa directive prefer = newer demande à Unison de résoudre automatiquement les conflits simples en gardant la version avec le timestamp le plus récent. C’est utile si tu sais que la dernière modification est toujours la bonne, mais cela suppose que les horloges des serveurs sont synchronisées par NTP. Sans cela, newer devient un tirage au sort.
Si tu préfères qu’une machine ait toujours raison en cas de conflit, remplace prefer = newer par force = /chemin/vers/la/source. Mais cette approche demande une rigueur absolue : toute modification directe sur les autres serveurs sera perdue à la prochaine synchronisation.
Pour lancer la synchronisation, une commande :
unison conf-servers -auto -batchL’option -auto accepte les propositions par défaut pour les cas sans conflit. L’option -batch empêche toute interaction en mode texte, ce qui est obligatoire dans un script CI.
Intégrée dans un pipeline de déploiement, cette commande est exécutée juste après la phase de tests de performance en préproduction. Ainsi, les fichiers qui ont validé le TTFB en recette sont exactement les mêmes qui arrivent sur les nœuds de production. Plus de dérive manuelle.
Si tu synchronises également les configurations entre les nœuds de production d’un cluster, ajoute un second root pointant vers le deuxième serveur. Unison gère plusieurs réplicas sans problème. Le processus va comparer chaque paire et propager les modifications. La seule contrainte : la synchronisation doit pouvoir se connecter en SSH à toutes les machines avec une clé privée chargée.
Un développeur qui travaille sur son poste local peut aussi monter un profil pour synchroniser ses fichiers de configuration Nginx de développement avec un serveur de test. Quand il itère sur des réglages de cache ou de compression et qu’il mesure le TTFB avec Lighthouse en local, il est certain que le serveur de test reflète exactement le même état. Cette cohérence est indispensable pour valider des optimisations avant de les pousser en recette. On en parlait justement dans un autre contexte : tout comme un state management centralisé avec Zustand garantit que tous les composants d’une app React partagent le même état, Unison garantit que tous les environnements partagent la même configuration serveur.
L’effet sur le TTFB se mesure en quelques minutes
Revenons à notre cas initial. Après avoir mis en place le profil Unison entre staging et production, le nginx.conf n’a plus jamais divergé. Le TTFB est resté stable, aux alentours de 190 ms en production, identique à la valeur mesurée en staging. Le LCP a suivi la même trajectoire.
La synchronisation régulière a aussi fait émerger un autre bénéfice : l’équipe a commencé à versionner les fichiers de configuration dans Git, en plus de la synchronisation Unison. Le fichier unique de référence est poussé sur le dépôt, puis déployé par Unison sur les environnements. Cela donne une traçabilité complète des modifications et permet de relier un changement de paramètre à une variation de Core Web Vitals dans les données de monitoring.
On ne prétend pas que la synchronisation de fichiers résout tous les problèmes de TTFB. La latence réseau, le temps de traitement applicatif, la lenteur des backends tiers restent des facteurs majeurs. Mais si vous avez optimisé le code et que le TTFB reste instable, vérifiez que la configuration de votre serveur web est la même partout. Le simple fait d’activer Brotli d’un côté et pas de l’autre suffit à créer un écart de plusieurs centaines de millisecondes sur des réponses volumineuses.
Ce que vous synchronisez d’autre peut aussi impacter vos Core Web Vitals
Les configurations serveur ne sont pas les seuls fichiers dont la cohérence influence les métriques de performance. Les scripts de build, les fichiers de variables d’environnement, les règles de pare-feu applicatif, les paramètres de CDN définis dans des fichiers YAML, tous ces éléments doivent être identiques entre les environnements de test et de production sous peine de fausser les mesures. Unison peut synchroniser n’importe quel répertoire, à condition de bien définir les règles d’exclusion.
Quand on compare des environnements de développement, la capacité à travailler sur plusieurs machines avec les mêmes fichiers est aussi un critère de productivité. Dans notre comparatif entre Claude Code et Cursor IDE, la synchronisation des préférences et des dossiers de projet entre un poste fixe et un portable était un point sensible. Unison excelle dans ce rôle, sans imposer de stockage cloud intermédiaire.
Pour aller plus loin sur les autres leviers qui réduisent le TTFB, vous pouvez consulter notre dossier sur l’optimisation des Core Web Vitals. La synchronisation de fichiers n’est qu’une pièce du puzzle, mais c’est celle qui empêche les régressions invisibles.
Questions fréquentes
Unison peut-il remplacer un outil de gestion de configuration comme Ansible ?
Pas vraiment. Unison synchronise des fichiers entre machines, mais ne génère pas de configuration à partir de templates et n’exécute pas de redémarrage de service. Ansible orchestre l’état complet d’un serveur. Les deux outils peuvent cohabiter : Unison maintient la cohérence des fichiers modifiés manuellement, Ansible déploie l’état cible initial.
Quelle est la différence avec Syncthing ?
Syncthing est un service de synchronisation continue pair-à-pair, idéal pour des postes de travail. Unison est une commande déclenchée manuellement ou en CI, conçue pour des synchronisations ponctuelles avec résolution fine des conflits. Pour des serveurs, Unison donne un contrôle plus granulaire sur le moment et la direction de la synchronisation.
Comment synchroniser des fichiers contenant des secrets sans les exposer ?
Les profils Unison peuvent référencer des fichiers de variables d’environnement ou des chemins externes, mais les secrets eux-mêmes ne devraient pas être gérés par Unison. Utilisez un gestionnaire de secrets type HashiCorp Vault pour injecter les valeurs sensibles au moment du déploiement. Unison synchronise la structure de configuration, pas les secrets qu’elle contient.
