La mission de Cal.com est de connecter un milliard de personnes d’ici 2031 grâce à une infrastructure open source de planification. Pour y parvenir, l’entreprise doit servir ses utilisateurs dans toutes les langues — et pendant des années, cette exigence a pesé en permanence sur la vélocité de l’équipe d’ingénierie.
Le problème : toujours en retard#
Cal.com avait tout essayé parmi les approches classiques. Des traducteurs participatifs via un système de gestion des traductions. Des agences de localisation. À chaque fois, plus de coûts et plus de coordination, pour le même résultat : même les langues les plus prioritaires restaient systématiquement désynchronisées.
« Nous étions toujours en retard sur l’internationalisation », se souvient Keith Williams, Head of Engineering. « Malgré nos investissements dans des agences et dans la traduction participative via des systèmes de gestion des traductions, même nos langues prioritaires n’étaient pas synchronisées. Les coûts étaient élevés, et le travail manuel détournait nos ingénieurs du développement de fonctionnalités. »
C’est un schéma fréquent. Les plateformes de localisation historiques gèrent les workflows des traducteurs humains — elles n’éliminent pas la surcharge de coordination, elles se contentent de l’organiser. Chaque cycle de publication impliquait un nouveau passage de relais à une équipe externe, un nouveau délai d’attente, une nouvelle phase de relecture. L’équipe d’ingénierie pouvait livrer une fonctionnalité en une journée ; sa localisation pouvait prendre deux semaines.
Le tournant : la localisation comme infrastructure#
En 2025, Cal.com a déployé un moteur de localisation sur Lingo.dev. Un est une API de traduction avec état : il conserve la terminologie produit de Cal.com, le vocabulaire propre au domaine de la planification et la configuration par langue d’une requête de traduction à l’autre. Lorsque le moteur rencontre « Workspace » ou « Booking » dans une chaîne en anglais, le glossaire détermine le terme approprié pour chaque langue avant même que le modèle ne génère le moindre token.
Le processus d’intégration a nécessité quelques ajustements initiaux, compte tenu de la base de code open source de Cal.com et de sa communauté de contributeurs. L’équipe de Lingo.dev s’en est chargée directement.
« Leur réactivité était hallucinante », raconte Williams. « Quand nous avions besoin d’ajustements, ils livraient des correctifs plus vite que tout ce que j’ai vu chez n’importe quel prestataire. »
Résultats#
Une fois le moteur de localisation configuré, Cal.com l’a connecté à son pipeline CI/CD. Chaque push de code déclenche le moteur ; les traductions se mettent automatiquement à jour dans les 36 langues.
- L’équipe d’ingénierie n’a plus à gérer les workflows de traduction
- Les 36 langues restent synchronisées à chaque publication
- Réduction significative des coûts de localisation par rapport aux dépenses en agence
- Zéro passage de relais — les traductions s’exécutent dans le même pipeline que les déploiements de code
« Le meilleur dans tout ça ? Nos ingénieurs ne pensent même plus à la localisation », explique Keith. « Ils développent simplement des fonctionnalités, et les traductions se font automatiquement. C’est exactement ce qu’il nous fallait pour rendre Cal.com accessible à tous, partout dans le monde. »
La suite#
Cal.com étend le moteur de localisation aux modèles d’e-mails — le dernier point de contact où les traductions étaient encore gérées séparément. Une fois cette étape franchie, chaque chaîne visible par l’utilisateur dans le produit passera par la même infrastructure de localisation.
Pour une équipe qui vise un milliard de connexions, l’effet cumulatif est déterminant : chaque terme de glossaire configuré aujourd’hui s’applique correctement à chaque nouvelle fonctionnalité, chaque nouvelle version et chaque nouvelle langue.
