Laurel est la plateforme d’intelligence du travail dédiée aux services professionnels. Les cabinets s’appuient sur Laurel pour automatiser le suivi du temps, comprendre ce qui alimente leur rentabilité et démontrer le ROI de leurs investissements en IA. Jusqu’à récemment, le produit n’existait qu’en anglais. Aujourd’hui, il est disponible dans plus d’une douzaine de langues – langues nordiques, français, néerlandais, portugais, espagnol, coréen – et le mandarin, le thaï, l’arabe, le japonais et le vietnamien sont déjà au programme.

L’intégration chez Laurel a été simple : l’essentiel de l’effort a consisté, de leur côté, à extraire et organiser les chaînes existantes pour préparer la base de code. L’alternative en interne était estimée à quatre à six mois de temps d’ingénierie, avec une maintenance continue à durée indéterminée. Nous avons constaté que le coût total du non-achat représentait environ 10x le coût d’achat, une fois intégrés les contrats qui auraient pu échapper. Aujourd’hui, ajouter une nouvelle langue prend une journée – et un product manager peut le faire seul. Il y a dix-huit mois, cette phrase aurait semblé absurde.

"J’ai aimé la façon dont Lingo.dev s’est mobilisé, a compris nos enjeux et a proposé des solutions. Nous n’avons pas eu besoin de créer une infrastructure de localisation – ils ont parfaitement réglé le sujet. Le pricing enterprise était juste, et nous échangeons dans un canal Slack partagé avec leurs ingénieurs. Sur les cas limites, le délai de traitement se compte en heures."

– Nick Bazley, Staff Product Manager, Laurel

À quel moment une entreprise SaaS doit-elle investir dans la localisation ?#

Nick Bazley est Staff Product Manager chez Laurel, où il passe depuis six ans à piloter des équipes produit tandis que l’entreprise déploie son produit à l’échelle mondiale. Cela faisait environ un an qu’il réfléchissait à la localisation avant de passer à l’action.

"Nous savions qu’il faudrait le faire un jour", explique Nick. "La question, c’était surtout : quand ? À chaque fois que nous en parlions, on arrivait à la même conclusion : ce serait un projet XXL, cela prendrait une éternité, et nous n’aurions pas une vision claire de la qualité du résultat."

Laurel était en pleine croissance, passant de clients mid-market à des entreprises internationales. Un schéma s’est imposé : signer un client dans une région, faire ses preuves, puis voir ce client vouloir se déployer dans d’autres régions.

À mesure que l’équipe commerciale recrutait partout en Europe et que les équipes customer success recevaient des demandes d’expansion, Nick voyait le problème arriver.

"Au moment où il a fallu s’y attaquer, nous étions environ 50 personnes. Construire nous-mêmes une infrastructure de localisation aurait été un chantier énorme – la moitié de l’équipe mobilisée pendant des mois, alors que nous avions déjà beaucoup d’autres sujets à développer pour nos clients."

Pourquoi acheter une infrastructure de localisation plutôt que la construire ?#

Laurel faisait face à deux options : acheter ou construire. Construire représentait probablement un effort sur plusieurs trimestres, avec une estimation interne de projet XXL – quatre à six mois de temps d’ingénierie. "Ce n’est pas un choix intelligent d’assumer le coût, le temps et les efforts nécessaires pour construire notre propre infrastructure de localisation. Le choix le plus rationnel, au stade de croissance où nous en étions, était d’acheter la meilleure solution du marché et de concentrer nos efforts sur notre plateforme cœur."

Dans cette réflexion, quatre critères ont vraiment fait pencher la décision : la rapidité de mise sur le marché, la scalabilité après le lancement, la personnalisation et la qualité.

"Nous ne sommes pas des experts de l’infrastructure de localisation. Nous ne savons pas quel sera le niveau de qualité. Pourquoi prendre ce risque quand une entreprise entière s’est construite autour de l’ingénierie de la localisation ?"

Comment évaluer une plateforme de localisation face à un TMS historique#

Nick a cartographié le marché avec une recherche rapide sur Perplexity Pro, parcouru les premiers résultats et trouvé un TMS historique. Une recherche Google séparée a fait remonter quelques autres options, et le Head of Engineering de Laurel était lui aussi tombé sur Lingo.dev de son côté.

Il a mené les deux évaluations en parallèle.

"À première vue, ce TMS historique ressemblait à une entreprise vraiment très aboutie", raconte Nick. "Mais quand nous avons regardé de plus près ce qu’ils proposaient, et ce dont nous avions besoin, il n’y avait qu’un seul choix possible pour atteindre le niveau de vitesse et de qualité que nous visons."

"Ce que j’ai apprécié, c’est la façon dont Lingo.dev s’est mobilisé : ils ont compris nos problèmes, ce que nous cherchions à faire, et ont proposé des solutions. Le pricing enterprise était juste. Et la promesse en matière de vitesse et de qualité a été le principal facteur de décision. Ce qui nous a vraiment marqués, c’est l’accès. Nous échangeons dans un canal Slack partagé avec les ingénieurs qui construisent réellement la plateforme. Quand nous tombons sur un cas limite, le délai de traitement se compte en heures. On a presque l’impression qu’ils font partie de l’équipe."

Quel niveau de précision attendre de la localisation IA pour la terminologie juridique et comptable ?#

Les utilisateurs de Laurel sont des professionnels du droit et de la comptabilité. Une interface allemande qui utilise le mauvais terme pour "billing rate" ou "matter" ne fait pas seulement mauvaise impression : elle érode la confiance dans l’ensemble du produit. En matière de terminologie juridique et comptable, la précision est indispensable.

Nick a testé la qualité avec de vrais clients. La première version a été envoyée à des clients nordiques ainsi qu’à un client français. L’équipe nordique n’a formulé aucun retour. Le client français, locuteur natif, n’a relevé que deux imprécisions : l’équipe les a immédiatement ajoutées au glossaire. Depuis, aucun problème n’a été signalé en néerlandais, portugais, espagnol, etc.

Nous avons testé la qualité sur 12 langues avec des clients de langue maternelle sur six mois. Nombre total de problèmes terminologiques signalés : deux, tous résolus le jour même grâce à des ajouts au glossaire. Il s’est avéré que le moteur de localisation, associé à un glossaire configuré, produisait une terminologie juridique plus cohérente qu’une logique de traduction développée de zéro – parce que le moteur impose les termes sur chaque paire de langues simultanément, ce qu’un processus manuel ne peut pas garantir.

"Cela fait un moment que nous n’avons pas eu besoin de retourner dans le glossaire pour ajuster quoi que ce soit", explique Nick.

Combien de temps faut-il pour ajouter une nouvelle langue à un produit SaaS ?#

Quand un customer success manager signalait qu’un client avait besoin du portugais dans l’interface, la demande finissait auparavant dans la roadmap, devait être priorisée, attendre un sprint, puis prenait des semaines.

Aujourd’hui, Nick crée un ticket, s’appuie sur un ancien ticket d’ajout de langue comme modèle, le transmet à AI Tooling, puis attend. L’outil ajoute alors la langue à la config, met à jour le sélecteur de langue et ouvre une PR. Un ingénieur relit la PR, la met en production, et Lingo.dev gère la localisation continue en pilote automatique.

"Une journée, c’est le délai de bout en bout – de la rédaction du ticket à la finalisation de la PR. Ça ne veut pas dire que j’y consacre une journée entière. La plupart du temps, je fais autre chose."

Avec des outils de code IA et une infrastructure de localisation Lingo.dev, Nick peut ajouter une langue sans mobiliser de ressources d’ingénierie.

"Avec Lingo.dev, n’importe qui dans l’entreprise peut désormais ajouter de nouvelles langues et ajuster nos moteurs de localisation. C’est assez remarquable."

Comment la vitesse de localisation influence-t-elle la vélocité des deals enterprise ?#

Le business case ne repose pas seulement sur le temps d’ingénierie économisé – même si cet avantage est bien réel. Il s’agit surtout de s’assurer que nous pouvons réagir rapidement à l’évolution des opportunités d’expansion.

"Avec les clients enterprise, une opportunité d’expansion peut surgir très vite", explique Nick. "Nos clients peuvent gagner de la traction dans un nouveau bureau, puis vouloir s’y développer si nous sommes capables de livrer rapidement le produit dans leur langue. Nous devons pouvoir réagir à cette vitesse, sans difficulté, pour poursuivre notre croissance."

Laurel a commencé avec cinq langues nordiques plus le français pour accompagner sa première expansion en Europe. Depuis, les équipes sales et customer success ont fait remonter des demandes pour le portugais, l’espagnol, le néerlandais – et aujourd’hui, de nombreuses autres discussions sont en cours à mesure que nous nous développons dans des bureaux à travers le monde.

Nous avons fait le calcul : dans les six mois qui ont suivi l’intégration, Laurel a ajouté sept langues en réponse à des demandes d’expansion clients. Chacune a pris moins d’une journée. Dans un modèle de développement en interne, ces sept langues auraient mobilisé environ 28 sprints d’ingénierie – une capacité qui a finalement été réallouée aux fonctionnalités cœur du produit.

Faut-il construire ou acheter son infrastructure de localisation ?#

Quand on lui demande ce qu’il dirait à un VP Product dans une entreprise comparable – B2B enterprise, utilisateurs professionnels, expansion internationale, équipe d’ingénierie déjà occupée par de vrais enjeux produit – Nick n’hésite pas.

"J’opterais à 100 % pour un fournisseur."

Ce qu’ils sous-estimeraient en choisissant de le construire eux-mêmes : "La complexité et la qualité. Vous ne savez pas à quoi ressemblera la qualité. Pourquoi prendre ce risque ?"

Ce qu’ils risqueraient de mal évaluer en choisissant un fournisseur : ne pas comprendre assez clairement leur propre problème pour choisir le bon. "Comprendre vraiment le problème que vous cherchez à résoudre et choisir le bon fournisseur pour ce problème précis – c’est essentiel."

Ce qu’il faut tester en premier : "La vitesse et le time-to-market. Ensuite, une fois la configuration initiale terminée, c’est la vitesse et la scalabilité."

Le vrai coût de l’attente#

La configuration initiale s’est faite en grande partie du côté de Laurel, avec la préparation de la stack technique. Ensuite : une journée par langue, sans sprint d’ingénierie, sans négociation de roadmap.

L’alternative, c’était trois à quatre mois de temps d’ingénierie pour développer la solution, une maintenance continue à perpétuité, et une qualité qu’ils ne pouvaient pas garantir dans des langues que personne dans l’équipe ne parle.

Nick le résume simplement : "L’infrastructure de localisation n’est pas un projet qu’on termine avant de passer à autre chose. C’est un sujet continu – chaque fois que vous changez d’échelle, chaque fois que vous entrez sur un nouveau marché, chaque fois que vous ajoutez une nouvelle fonctionnalité. Cela doit être simple. Je n’ai pas envie de revenir sans cesse voir l’équipe d’ingénierie pour demander un sprint supplémentaire afin de livrer tout ce dont nous avons besoin."

Ce que cela implique pour les équipes produit qui se développent sur de nouveaux marchés#

L’expérience de Laurel reflète une réalité bien connue des entreprises SaaS B2B confrontées à une demande internationale de la part des grands comptes : la localisation cesse d’être une simple demande produit pour devenir un frein à la croissance. La question n’est plus « devons-nous localiser ? », mais « à quelle vitesse pouvons-nous dire oui au prochain marché ? »

Trois facteurs ont guidé l’approche de Laurel : l’équipe ne pouvait pas se permettre de mobiliser des ressources d’ingénierie sur une infrastructure qui ne relève pas de son cœur de produit. Et la qualité de la terminologie juridique et comptable devait être vérifiable, pas simplement présumée.

L’approche d’ingénierie de la localisation considère la prise en charge des langues comme une couche de configuration, et non comme un projet d’ingénierie. Un chef de produit peut ajouter une langue sans sprint dédié, sans mobiliser l’équipe d’ingénierie et sans coordonner un prestataire de traduction. Pour les équipes dont la vitesse d’expansion sur de nouveaux marchés conditionne la croissance du chiffre d’affaires, ce changement opérationnel fait toute la différence entre saisir une opportunité et la voir se refermer.

Laurel développe une IA destinée aux professionnels du droit et de la comptabilité. L’entreprise déploie son produit dans plus d’une douzaine de langues, et peut en ajouter une nouvelle en une journée. Son infrastructure de localisation repose sur Lingo.dev.

Questions fréquentes#

Combien de temps faut-il pour ajouter une nouvelle langue à un produit SaaS ?

Chez Laurel, l’ajout d’une nouvelle langue prend environ une journée de bout en bout. Un chef de produit crée un ticket en s’appuyant sur l’ajout précédent d’une langue, le confie à un agent IA de génération de code, puis un ingénieur relit la PR. Aucun sprint dédié, aucune coordination avec un prestataire. L’alternative envisagée auparavant — construire l’infrastructure de localisation en interne — était estimée à quatre à six mois avant de pouvoir lancer la moindre langue.

Une startup doit-elle développer ou acheter son infrastructure de localisation ?

Nick Bazley, Staff PM chez Laurel, a comparé le développement en interne à l’achat. Sa conclusion : « Nous ne sommes pas les experts de l’infrastructure de localisation. Nous ne savons pas quel niveau de qualité nous allons obtenir. Pourquoi prendre ce risque alors que quelqu’un a bâti toute une entreprise autour de l’ingénierie de la localisation ? » L’estimation du développement en interne correspondait à un projet XXL qui aurait mobilisé la moitié de l’équipe d’ingénierie pendant des mois.

Quel niveau de précision peut offrir la localisation par IA pour une terminologie spécialisée ?

Laurel a mené des tests sur 12 langues avec des clients natifs du secteur juridique et comptable, sur une période de six mois. Nombre total de problèmes terminologiques : deux, tous deux résolus dans la journée grâce à des ajouts au glossaire. Le moteur de localisation garantit la cohérence du glossaire sur chaque paire de langues, simultanément — ce qu’une approche manuelle ne peut pas assurer à grande échelle.

Quel est l’impact de la vitesse de localisation sur les cycles de vente enterprise ?

Le constat de Laurel est clair : lorsqu’un client grand compte demande la prise en charge d’une nouvelle langue, il attend une réponse en quelques jours, pas en plusieurs mois. Nick Bazley résume bien la situation : « L’opportunité ne reste pas ouverte très longtemps. Si nous ne sommes pas capables de nous retourner en une semaine, la fenêtre peut se refermer. » Après être passée à une infrastructure de localisation, Laurel a ajouté sept langues en six mois — chacune en moins d’une journée.

Comment se compare le coût du développement interne à celui de l’achat pour la localisation ?

La comparaison de Laurel est simple : une courte phase d’intégration et un coût récurrent à l’usage, contre quatre à six mois de temps d’ingénierie pour développer la solution, auxquels s’ajoutent une maintenance à durée indéterminée et une qualité qu’ils ne pouvaient pas garantir. Les sept langues ajoutées en six mois auraient mobilisé environ 28 sprints d’ingénierie dans le modèle de développement interne — une capacité qui a pu être réallouée aux fonctionnalités du cœur de produit.