Scribe simplifie les signatures e-mail et les rend mesurables : une entreprise peut déployer des signatures cohérentes, fidèles à sa marque, à l’échelle de toute l’organisation, sans configuration par employé, et transformer la signature en canal de revenus mesurable. L’entreprise a cinq ans et affiche un fort product-market fit. Lors d’une refonte complète du produit, Scribe a lancé l’ensemble de son produit et de sa documentation en 16 langues. L’intégration a pris moins d’une journée ; ensuite, les deux fondateurs ont géré eux-mêmes la localisation, sans recrutement ni agence. Ils ont configuré le moteur – glossaire, voix de marque, instructions par langue et notation de qualité par IA sur chaque traduction – en itérant avec Claude via le serveur MCP de Lingo.dev.

"Lingo.dev nous a donné un moteur de localisation que nous pilotons via une API, un MCP et un CLI, directement dans notre stack. Pour une équipe d’ingénieurs, c’est une évidence."

Clément Champau, CEO et cofondateur, Scribe

Pourquoi localiser maintenant, après cinq ans#

L’IA a rendu la localisation viable pour une équipe de deux personnes, et le timing coïncidait avec une refonte complète du produit – nouvelle UI, nouvelle UX, et moment idéal pour annoncer 16 langues. Après cinq ans, Scribe avait atteint un fort product-market fit et une UI stable, de sorte qu’une retraduction ne risquait pas d’être constamment remise en cause par les changements d’interface.

Le marché allait dans le même sens. Certains acheteurs enterprise sont encore en phase de numérisation plutôt que d’adoption de l’IA, et dans plusieurs marchés, un produit qui ne parle pas la langue locale crée de la friction dans le processus commercial. Scribe a commencé là où se trouvait le chiffre d’affaires : le français, y compris l’Afrique francophone ; l’espagnol, avec l’Amérique latine en priorité ; et l’anglais. À elles trois, ces langues couvrent la majeure partie du monde occidental ainsi que l’Amérique latine. Ensuite, l’entreprise s’est attaquée aux marchés au PIB le plus élevé – Suisse, Norvège, Suède. « PIB le plus élevé en Europe, PIB le plus élevé au monde », a dit Clément.

Pourquoi une plateforme pensée pour les équipes d’ingénierie a fait la différence#

Clément a découvert Lingo.dev via l’annuaire Y Combinator ; il garde un œil sur les nouveaux outils YC et les adopte tôt. Ce qui a fait la différence, c’est la place de la plateforme dans la stack. Lingo.dev est une plateforme d’ingénierie de la localisation : un moteur de localisation configurable – glossaire, voix de marque, instructions par langue et notation de qualité par IA qui évalue le résultat de manière indépendante – piloté par une API, un serveur MCP et un CLI. Il intervient à la toute première couche du processus de développement, de la même manière qu’une équipe exploite le reste de son infrastructure.

"Nous voulions quelque chose au tout premier niveau du processus de développement. Il faut une API, il faut un MCP – et une fois qu’on a ça, on peut brancher ce type de Lego dans notre workflow d’agent très facilement."

Gil, cofondateur et CTO de Scribe, a lu la documentation de l’API, l’a jugée solide et a tout intégré en moins d’une journée.

"Je l’ai envoyé à Gil. Il a lu la documentation de l’API, a dit que ça avait l’air sérieux, et en moins d’une journée, tout était implémenté."

Comment le CEO a configuré l’intégralité du moteur via le MCP#

Après l’intégration en une journée, Clément a configuré lui-même l’intégralité du moteur – voix de marque, glossaire et instructions par langue – via le serveur MCP de Lingo.dev, bien qu’il ne soit pas développeur. La configuration finale était conséquente : 16 voix de marque, 133 instructions et 644 termes de glossaire.

La boucle était très concrète. Il lançait une langue, ouvrait l’application, faisait des captures d’écran, puis les renvoyait via le MCP : ici, l’appel à l’action ne fonctionnait plus ; ici, l’UI cassait. Claude ajustait les trois leviers – glossaire, instructions, voix de marque – jusqu’à obtenir un résultat solide. Ensuite, il lançait la traduction complète et déployait le reste.

"Je lançais une langue, je regardais l’application, je faisais des captures d’écran, puis je les renvoyais via le MCP – ici, le CTA ne fonctionnait plus, ici, l’UI cassait – et Claude adaptait le glossaire, les instructions et la voix de marque jusqu’à ce que ce soit bon."

L’agent prenait aussi des initiatives au sein du même workflow. En optimisant le SEO de la page d’accueil reconstruite, Claude a signalé que Google traitait les pages localisées comme des versions de repli de la page anglaise, plutôt que comme des cibles de langue indépendantes. Comme il disposait d’un accès MCP au moteur, il a relancé la synchronisation Lingo.dev pour corriger cela.

Comment valider la qualité des traductions dans des langues qu’on ne parle pas ?#

Le moteur mesure lui-même la qualité de son résultat. Sur les exécutions de Scribe, la notation de qualité par IA a atteint en moyenne environ 87 sur 100, avec près de 96 % des traductions notées à 70 ou plus – un signal de qualité dans 16 langues que les deux fondateurs ne lisent pas eux-mêmes.

Scribe livre à environ 95 % et considère la post-édition humaine comme le moyen de combler l’écart final à mesure que l’entreprise passe à l’échelle. Le raisonnement est simple : un produit qui résout un vrai problème ne perd pas un utilisateur à cause d’une traduction qui n’est pas parfaitement peaufinée.

"Même à 95 %, c’est largement suffisant. Si vous résolvez un vrai problème et que l’utilisateur veut la solution, une traduction qui n’est pas parfaite ne l’empêchera pas d’utiliser le produit."

Faut-il développer sa localisation en interne ou l’acheter ?#

Clément a recommandé Lingo.dev à l’un de ses investisseurs, un CTO qui avait déjà construit une solution de localisation en interne. Sa réaction a tranché la question du build-versus-buy.

"J’ai recommandé Lingo.dev à l’un de nos investisseurs, qui est aussi CTO. Il avait construit la localisation en interne, et sa réaction a été : c’est exactement ce que nous aurions dû utiliser. Si je l’avais su, j’aurais investi chez eux."

Le coût qui a surpris Scribe n’était pas le build initial. C’était la maintenance – les cas limites qui continuent d’arriver, sans fin, et les décisions permanentes sur la manière d’améliorer le système.

"Rien n’est simple. Dès qu’on commence à gérer tous les cas limites – et ils continuent d’arriver sans arrêt –, cela demande un vrai travail de maintenance. Mieux vaut brancher quelque chose de pensé pour les équipes d’ingénierie et savoir qu’une équipe travaille dessus 24 h/24."

Avec l’IA qui exécute le travail, la valeur se déplace vers celles et ceux qui conçoivent le système. Le moteur de localisation – glossaire, voix de marque, instructions et notation de qualité par IA – constitue une architecture qu’une équipe interne travaillant sous pression a peu de chances de concevoir aussi bien.

Le frein côté facturation, et la correction#

Au début, la visibilité sur les coûts était limitée. Clément devait lancer une exécution et actualiser l’interface pour vérifier que les crédits ne seraient pas épuisés en cours de route ; quand c’était le cas, l’exécution s’arrêtait et il devait la relancer. Il a remonté le problème, et les correctifs ont été livrés dans la même semaine : une estimation du coût avant exécution et un indicateur d’usage avec recharge automatique.

"Maintenant, je peux voir combien de temps une exécution prendra et ce qu’elle coûtera avant de la lancer. Avant, je devais lancer une exécution et continuer à actualiser pour m’assurer que les crédits ne s’épuisaient pas, parce que quand c’était le cas, tout s’arrêtait et nous devions redémarrer."

Ce changement lui a permis de se projeter à l’avance – durée d’exécution et coût connus avant même de lancer une exécution. Le contraste qu’il soulignait, c’était entre déposer une demande puis attendre, et voir le changement demandé livré dans la semaine. « Félicitations pour la rapidité de la boucle d’itération », a-t-il dit.

Où ils en sont aujourd’hui#

Scribe fait tourner quatre applications – application web, application desktop et autres – ainsi que sa documentation, toutes à partir de l’anglais, toutes via un seul moteur de localisation. L’autosync est désactivé pour le moment ; Gil déclenche les exécutions manuellement après les mises en production majeures, une habitude héritée d’un ancien problème de crédits et renforcée par le faible nombre de changements après la grande sortie. Le plan est d’activer l’autosync une fois que tout sera totalement stable, afin qu’un seul push déploie chaque application et la documentation.

Le serveur MCP est l’une des trois portes d’entrée vers la plateforme, aux côtés de l’API et du CLI. La plupart des MCP sont en lecture seule ou limités par le contexte ; celui de Lingo.dev permet à une personne non développeuse de configurer l’intégralité du moteur de localisation, ce qui a libéré Gil pour passer à autre chose après cette journée de mise en place.

"Je n’ai même pas passé tant de temps que ça dans l’interface, mais il a très bien fait le travail."

Le moteur s’est chargé de la traduction ; Clément s’est chargé de la configuration.

Ce que cela signifie pour les petites équipes qui localisent des logiciels#

Le déploiement de Scribe met en lumière une dynamique qui dépasse les signatures e-mail. Pour une équipe d’ingénieurs, la localisation est passée d’un problème de main-d’œuvre à un problème de conception système. La traduction est prise en charge par les modèles ; le travail qui reste consiste à configurer le moteur qui les orchestre – le glossaire, la voix de marque, les instructions par langue et la notation de qualité par IA qui évalue le résultat.

Ce basculement change l’équation du build-versus-buy. La partie coûteuse de la localisation en interne n’a jamais été la première version – c’était la maintenance : les cas limites, les changements de modèles et les règles par langue qui s’accumulent avec le temps. Une plateforme d’ingénierie de la localisation absorbe tout cela, ce qui explique pourquoi une équipe de deux personnes peut gérer 16 langues sans recrutement dédié à la localisation.

Trois conditions permettent de généraliser cette approche à d’autres équipes. Le contenu source vit dans le contrôle de version. Le moteur est piloté par une API, un CLI et un serveur MCP, il s’intègre donc au workflow qu’une équipe utilise déjà. Et la notation de qualité par IA rend le résultat mesurable dans des langues que personne dans l’équipe ne parle – toute la différence entre faire confiance à une traduction et la vérifier.

Dans leurs mots#

"Avec une IA qui exécute aussi bien, la valeur est désormais du côté de l’architecte – c’est le meilleur concepteur de systèmes qui gagne. Si je l’avais construit moi-même, je n’aurais pas conçu un système aussi bon."

"J’ai recommandé Lingo.dev à l’un de nos investisseurs, qui est aussi CTO. Il avait construit la localisation en interne, et sa réaction a été : c’est exactement ce que nous aurions dû utiliser. Si je l’avais su, j’aurais investi chez eux."

"Lancez une langue pour le marché que vous voulez ouvrir. Implémentez-la, testez le MCP – il fait le travail tout seul. Le vrai déclic, c’est le MCP."

Clément Champau, CEO et cofondateur, Scribe

Scribe est la plateforme de signatures e-mail utilisée par des milliers d’entreprises pour déployer, à l’échelle de toute l’organisation, des signatures cohérentes et fidèles à leur image de marque, sans configuration individuelle, et en faire un canal de revenus mesurable. Ses deux fondateurs pilotent le produit et la documentation en 16 langues, configurés comme un moteur de localisation unique qu’ils exploitent comme le reste de leur infrastructure. Leur localisation tourne sur Lingo.dev.

Questions fréquentes#

Combien de temps faut-il pour intégrer un moteur de localisation ?

Moins d’une journée. Le CTO de Scribe a lu la documentation de l’API, l’a jugée solide, puis a branché l’API de Lingo.dev sur le workflow d’agent existant en moins d’une journée. La configuration du moteur — glossaire, voix de marque et instructions par langue — a ensuite été réalisée séparément, sous la conduite du CEO via le serveur MCP.

Une personne non développeuse peut-elle configurer un moteur de localisation ?

Oui. Après cette journée d’intégration, le CEO de Scribe — technique, mais pas développeur — a configuré lui-même l’ensemble du moteur via le serveur MCP de Lingo.dev : lancer une langue, passer l’application en revue, puis demander à Claude d’ajuster le glossaire, les instructions et la voix de marque jusqu’à ce que le résultat soit au niveau attendu. Au final, la configuration comprenait 16 voix de marque, 133 instructions et 644 termes de glossaire.

Comment validez-vous la qualité des traductions dans des langues que vous ne parlez pas ?

Scribe s’appuie sur un scoring qualité par l’IA : chaque traduction est évaluée par un modèle indépendant de celui qui l’a produite. Sur l’ensemble des exécutions de Scribe, le score moyen était d’environ 87 sur 100, avec près de 96 % des traductions obtenant 70 ou plus. Cela donne à une équipe de deux personnes un signal qualité mesurable dans 16 langues qu’elle ne lit pas elle-même, la post-édition humaine étant réservée à la dernière ligne droite.

Faut-il développer la localisation en interne ou l’acheter ?

Scribe, c’est deux fondateurs techniques qui auraient très bien pu développer la localisation en interne. Ils ont choisi une plateforme après avoir évalué le coût de maintenance, pas celui de la première implémentation. L’un de leurs investisseurs, un CTO qui l’avait développée en interne, l’a dit sans détour : c’est exactement ce qu’on aurait dû utiliser. Le coût qui s’accumule, ce sont les cas limites et les règles propres à chaque langue au fil du temps, pas la première version.

Que fait concrètement un ingénieur en localisation ?

Moins de traduction, plus de configuration. Chez Scribe, le travail consistait à mettre en place le moteur — glossaire, voix de marque, instructions par langue — puis à l’ajuster à partir des scores qualité de l’IA, plutôt qu’à gérer des traducteurs ou des fichiers. Le rôle se rapproche davantage de l’ingénierie de plateforme que de la coordination de prestataires : il s’agit de concevoir et d’exploiter le système qui produit les traductions, plutôt que de gérer les personnes qui les produisent.

Que diriez-vous à un pair en train de l’évaluer ?

"Lancez une langue pour le marché que vous voulez ouvrir. Mettez-la en place, testez le MCP — il fait le travail tout seul. Le vrai déclic, c’est vraiment le MCP."