Vous migrez votre agenda, et soudain la moitié de vos titres ressemblent à du bruit : réunion, d’accord, café. En français, où presque chaque phrase contient un accent ou une apostrophe, ce piège ne touche pas quelques événements : il les défigure tous. Bonne nouvelle : ce n’est pas aléatoire, et une fois qu’on comprend le mécanisme, c’est totalement évitable.
Ce que vous voyez vraiment
Voici les dégâts les plus courants sur un agenda français. Si vous reconnaissez ne serait-ce qu’une ligne, vous êtes face au même bug :
| Vous aviez écrit | Après import | Ce qui s’est passé |
|---|---|---|
| réunion | réunion | le « é » (octets C3 A9) relu en Windows-1252 |
| l’équipe | l’équipe | apostrophe courbe et accent, relus octet par octet |
| d’accord | d’accord | l’apostrophe courbe (U+2019, octets E2 80 99) éclatée en trois |
| café — 14h | café — 14h | accent et tiret cadratin, double-encodés ensemble |
Le motif est toujours le même : un caractère « normal » remplacé par deux ou trois symboles qui commencent presque toujours par à ou â€. Ce n’est pas du hasard — c’est une signature.
Le mécanisme : une double conversion
Tout texte est, au fond, une suite d’octets. L’encodage est la convention qui dit quel octet représente quelle lettre. Deux conventions s’affrontent ici :
- UTF-8 — le standard moderne, universel. Le « é » y est codé sur deux octets :
C3 A9. - Windows-1252 / Latin-1 — un vieux jeu de caractères sur un seul octet. Le « é » y tient sur un octet :
E9.
Le drame se joue en deux temps. Votre agenda est exporté correctement en UTF-8 : le « é » est bien C3 A9. Mais un outil de la chaîne — un script de découpe, un éditeur de texte mal configuré, un import qui n’a pas lu la bonne déclaration — croit lire du Windows-1252. Il interprète donc chacun des deux octets séparément :
Octets UTF-8 du « é » : C3 A9
Relu en Windows-1252 : Ã ©
Résultat affiché : « é »
L'apostrophe courbe « ’ » (U+2019) :
UTF-8 : E2 80 99
Relu en Windows-1252 : â € ™
Résultat affiché : « ’ »C’est tout. Aucune donnée n’est perdue à ce stade — l’information est toujours là, simplement lue avec la mauvaise grille. C’est ce qu’on appelle un mojibake, et sa signature à / †trahit à chaque fois une lecture Windows-1252 d’un texte UTF-8.
D’où vient l’erreur, concrètement
Dans une migration d’agenda, trois coupables reviennent sans cesse :
- La déclaration d’encodage manquante. Le fichier
.icsest de l’UTF-8, mais rien ne le dit explicitement. L’outil d’import applique son réglage par défaut — souvent Windows-1252 sur les systèmes anciens. - Le passage par un tableur. Ouvrir puis ré-enregistrer un export via Excel ou un CSV intermédiaire est une cause classique : le tableur ré-encode dans son propre jeu de caractères local.
- La découpe manuelle du fichier. Pour passer sous la limite de 1 Mo de Google, beaucoup ouvrent le
.icsdans un éditeur et le recoupent — et un éditeur mal réglé ré-enregistre dans le mauvais encodage au passage.
Pourquoi un « rechercher-remplacer » ne suffit pas
La tentation est de corriger après coup : remplacer é par é, ’ par ’, et ainsi de suite. Ça marche pour les deux ou trois cas évidents, mais il existe des dizaines de combinaisons (chaque caractère accentué, chaque guillemet, tiret, espace insécable, emoji…), et certaines séquences sont ambiguës. Sur un agenda de plusieurs centaines d’événements, vous passerez à côté de cas, et vous risquez d’en casser d’autres qui étaient corrects. C’est un colmatage, pas une réparation.
Comment SoftHop l’évite, par construction
Le mojibake naît toujours d’un fichier qui transite entre deux outils sans porter son encodage. La parade la plus sûre, c’est de ne jamais produire ce fichier.
SoftHop ne fait pas d’export/import ICS : on lit les événements directement via l’API Google Agenda, où le texte est déjà de l’UTF-8 sans ambiguïté, et on les écrit sur le compte cible par la même API. Aucun fichier intermédiaire, aucun ré-enregistrement, aucune chaîne d’outils où un maillon peut se tromper de grille de lecture.
Si vous voyez déjà des à dans votre nouvel agenda, ne tentez pas de tout réparer à la main : repartez de la source, encore intacte, et migrez-la sans la faire transiter par un fichier. C’est tout l’intérêt d’une migration de compte à compte.