En 2021, un client allemand du secteur du e-commerce est venu voir Seahawk avec un brief qui disait essentiellement : « Nous avons besoin de notre boutique WooCommerce en anglais, français et polonais. D'ici mars. » On était en novembre. Et le budget pour une traduction humaine était, disons, ambitieux dans la mauvaise direction. On avait utilisé l'API de Google Translate sur quelques projets avant et le résultat était, honnêtement, embarrassant pour tout ce qui dépassait les libellés de boutons. Alors j'ai cherché ailleurs.
C'est à ce moment-là que j'ai vraiment pris le temps d'explorer DeepL. Je l'avais vu mentionné dans quelques threads de développeurs mais je n'avais pas pris ça au sérieux. La plus grosse erreur que j'ai commise en cette demi-décennie. Une fois que j'ai passé les mêmes descriptions de produits dans les deux APIs et montré au client les résultats côte à côte, il n'y avait pas de débat. On a livré la boutique allemande en trois langues avant Noël, le client a ajouté le néerlandais six mois plus tard sans problème, et ce projet est toujours un de ceux que je montre quand les gens me demandent à quoi ressemble une bonne intégration d'API.DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
Ce post parle de la réalité pratique de l'intégration de DeepL dans un site web. Pas du discours marketing. Les vraies décisions d'implémentation, le modèle tarifaire, les pièges, et ce que je dirais à mon moi du passé avant de commencer.
Pourquoi DeepL surpasse vraiment les alternatives
Soyons directs : pour les langues européennes, DeepL est dans une catégorie à part. Le modèle a été entraîné massivement sur le corpus Europarl et d'autres textes parallèles de haute qualité, et vous le sentez immédiatement dans les résultats pour l'allemand, le français, l'espagnol, l'italien, le néerlandais, le polonais et le portugais. La structure des phrases semble réfléchie plutôt que simplement échangée mot pour mot.
L'API Google Translate (v2 et v3) est moins chère et couvre davantage de langues. 133 contre les 29 langues supportées par DeepL en mi-2024. Si vous avez besoin du swahili ou du bengali, DeepL n'est pas votre solution. Point final. Mais si votre client s'étend à travers l'UE ou au Japon (DeepL gère le japonais remarquablement bien), vous lui rendriez un mauvais service en optant par défaut pour Google par habitude.
L'autre chose dont personne ne parle assez : le paramètre de formalité de DeepL. Vous pouvez définir formality=more ou formality=less et l'API ajustera le registre de la sortie en conséquence. C'est énorme pour l'allemand, où du/Sie n'est pas un choix stylistique mineur. Une marque de mode DTC veut un registre différent d'une entreprise B2B SaaS. J'ai eu des clients remarquer cette distinction dans leur copie traduite sans même que je le leur pointe.formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
Comprendre le modèle de coûts avant de vous engager
DeepL facture par caractère traduit. Le plan API gratuit (DeepL API Free) vous donne 500 000 caractères par mois. Ça semble énorme jusqu'à ce que vous traduisiez un catalogue WooCommerce avec 800 produits et des descriptions longues.
Le plan Pro commence autour de $6.99/mois pour 500 000 caractères et augmente à partir de là. Pour la plupart des projets d'agence que je gère, le coût se situe quelque part entre $15 et $60 par mois selon la taille du catalogue et la fréquence de mise à jour. Comparez ça aux tarifs de traduction humaine professionnelle (généralement £0.10 à £0.18 par mot sur le marché britannique) et l'API s'amortit en moins de 200 mots.
Une chose qui m'a brûlé tôt : la gestion du HTML. DeepL peut recevoir du HTML brut et tentera de préserver les balises plutôt que de les traduire. Vous passez tag_handling=html dans votre requête. Mais si votre HTML est mal formé ou que vos descriptions de produits contiennent des scripts en ligne (je regarde vous, certains plugins WooCommerce), la sortie peut être déformée. J'ai appris à assainir le contenu avant qu'il ne frappe l'API, pas après.HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
Les deux chemins d'intégration : WordPress et constructions personnalisées
Sites WordPress
Pour WordPress, le chemin le plus direct que j'ai utilisé est l'intégration WPML. WPML a un connecteur DeepL natif intégré dans son module Translation Management. Vous autorisez votre clé API DeepL dans les paramètres de WPML, sélectionnez les types de contenu à auto-traduire, et ça gère la file d'attente. Ce n'est pas magique, une étape de révision humaine vaut toujours la peine d'être intégrée au flux, mais pour un site de 300 pages ça vous épargne des semaines.WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
L'alternative est Polylang Pro avec l'add-on DeepL. Licence un peu moins chère, un peu moins polie sur le côté gestion de traduction. J'ai utilisé Polylang sur un site de groupe de restaurants français l'année dernière. Correct pour cette échelle. Mais pour tout ce qui a des types de posts personnalisés et des champs ACF, WPML gère mieux les cas limites selon mon expérience.
Si vous construisez du WordPress headless (front-end Gatsby ou Next.js tirant des données de WP via GraphQL), vous voudrez appeler l'API DeepL directement depuis votre pipeline de build ou une fonction serverless. N'essayez pas de le faire passer par un plugin dans cette architecture. Ça ne scale pas proprement.
Custom / Non-WordPress Builds
C'est là que ça devient intéressant. DeepL publie des bibliothèques client officielles pour Python, Node.js, PHP, Ruby, .NET et Java. La bibliothèque Node.js est solide. Je l'ai utilisée sur un projet Next.js où nous avons mis en cache les traductions dans Redis pour éviter les appels API redondants sur les chaînes répétées.official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
Un appel Node.js basique ressemble à ceci :
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
Simple. La vraie question architecturale, c'est le caching. Vous ne voulez pas frapper l'API à chaque chargement de page. Stockez les traductions dans votre base de données ou une couche de cache (Redis fonctionne bien, même un simple fichier JSON fait l'affaire pour les petits sites). Invalidez le cache quand le contenu source change. C'est tout. La plupart de la complexité se trouve dans la logique d'invalidation du cache, pas dans l'appel API lui-même.
Handling Placeholders and Dynamic Content
C'est ce qui a piégé l'un de mes développeurs chez Seahawk sur un projet SaaS où les chaînes d'interface contenaient des variables comme {{user_name}} et {{count}}. Envoyez-les bruts à DeepL et il va parfois traduire les noms de variables. Pas idéal quand {{nombre_de_usuario}} se retrouve dans votre interface en espagnol.{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
La solution : utiliser le traitement XML de DeepL et envelopper vos placeholders dans des balises ignore avant d'envoyer.XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
Définissez tag_handling=xml et ignore_tags=deepl:ignore dans vos paramètres de requête. L'API préserve tout ce qui se trouve à l'intérieur de ces balises. C'est documenté dans la référence API de DeepL mais c'est facile à rater à la première lecture. Ça m'a coûté environ trois heures de débogage sur ce projet SaaS. J'espère que ça ne vous en coûtera aucune.tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
Construire un flux de révision sensé
La traduction automatique n'est pas un bouton de publication. Je ne recommanderais jamais de déployer la sortie DeepL directement sur un site en direct sans au moins une relecture d'un locuteur natif, particulièrement pour tout ce qui est orienté client. Mais le flux de travail n'a pas besoin d'être pénible.
Voici ce que j'ai mis en place pour la plupart des projets clients :
- Lancer la traduction initiale via l'API DeepL.
- Pousser la sortie vers une table de traduction de staging (dans WPML c'est automatique ; dans les builds personnalisés j'écris dans une table de base de données translations avec une colonne status définie par défaut à pending).
translationsDB table with astatuscolumn defaulting topending). - Envoyer un lien au relecteur du client sur le marché (souvent l'équipe locale du client lui-même ou un freelancer de ProZ).ProZ).
- Le relecteur édite directement dans le CMS ou une interface de révision simple que je construis.
- Le statut passe à approved, le contenu devient live.
approved, content goes live. - Verrouiller la chaîne pour qu'elle ne soit pas écrasée lors de la prochaine synchronisation API.
Cette dernière étape compte. J'ai vu des configurations où une mise à jour de contenu dans la langue source déclenche une retradution complète et efface toutes les corrections manuelles. Construisez le mécanisme de verrouillage avant de construire quoi que ce soit d'autre.
Considérations SEO pour les sites multilingues
Le contenu traduit seul ne se classera pas. Vous avez besoin de balises hreflang dans votre <head> HTML pour chaque variante de langue, et elles doivent être correctes. Une configuration hreflang mal appairée peut en fait supprimer vos pages internationales des résultats de recherche. J'ai vu cela arriver à un client qui avait un magnifique site français traduit resté en obscurité pendant quatre mois parce que quelqu'un s'était trompé sur les codes de langue ( fr-FR vs fr).hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).
Au-delà de hreflang : les URLs traduites. Idéalement, vous voulez aussi que les slugs soient traduits, pas /fr/how-to-cook-pasta mais /fr/comment-cuire-les-pates. DeepL peut traduire les slugs mais vous voudrez les passer par un formateur de slug après (minuscules, tirets, supprimer les caractères spéciaux). WPML fait cela automatiquement. Dans les builds personnalisés, gérez-le manuellement./fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
Et les métadonnées. Les titres de page, les méta descriptions, le texte alt sur les images. Tout cela a besoin d'un traitement de traduction. Je fais passer les métadonnées par DeepL séparément dans le pipeline, pas dans le lot de contenu du corps. C'est plus facile pour contrôler les limites de caractères de cette façon.
Où DeepL a des limites
Réponse honnête : la terminologie spécifique à la marque. DeepL ne sait pas comment votre client appelle ses fonctionnalités de produit. Si un client fintech utilise « Smart Vault » comme nom de produit, DeepL le traduira. À chaque fois.
La solution est la fonction glossaire de DeepL. Vous définissez des paires de termes via l'API (terme source, terme cible, paire de langues) et attachez l'ID du glossaire à vos demandes de traduction. Ce Smart Vault devient « Smart Vault » dans chaque langue parce que vous le lui avez dit. Vous pouvez gérer les glossaires programmatiquement ou via le tableau de bord de DeepL. Je configure maintenant des glossaires dans le lancement de chaque projet. Cela prend 20 minutes et évite une catégorie d'erreurs qui coûterait sinon des heures à attraper en relecture.glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
L'autre limite honnête : la couverture linguistique de DeepL. 29 langues est vraiment restrictif si votre client a des ambitions au-delà de l'Europe et de l'Asie de l'Est. Si vous avez besoin de l'arabe, vous cherchez une approche hybride : DeepL pour les langues européennes, Google Cloud Translation ou Microsoft Azure Translator pour tout le reste, unifiés derrière une seule couche API interne qui achemine selon la paire de langues. C'est ennuyeux à construire une fois. Très pratique à maintenir.
FAQ
L'API DeepL est-elle gratuite ?
Il y a un tier gratuit avec 500 000 caractères par mois, ce qui est généreux pour les tests et les petits projets. Le plan gratuit nécessite une carte de crédit en fichier mais ne vous facturera pas à moins que vous dépassiez la limite ou que vous passiez à un plan payant. Pour les sites en production avec un trafic ou un volume de contenu réel, vous voudrez presque certainement un plan payant. Les tiers Pro commencent à environ 6,99 $/mois et augmentent selon l'utilisation des caractères.
Puis-je utiliser DeepL avec WordPress sans plugin ?
Techniquement oui. Vous pouvez appeler l'API REST directement depuis un plugin personnalisé WordPress ou functions.php en utilisant wp_remote_post(). Mais à moins que vous aimiez réinventer la roue, les intégrations WPML ou Polylang gèrent la file de traduction, la synchronisation des chaînes et le verrouillage du contenu pour vous. Je ne passerais à une API custom-directe dans WordPress que si vous aviez une raison architecturale très spécifique.wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
Quelle est la précision de DeepL comparée à la traduction humaine ?
Pour les langues européennes, DeepL affiche régulièrement des scores à quelques points de pourcentage de la traduction humaine selon les benchmarks BLEU. Concrètement : suffisant pour les descriptions de produits et les chaînes d'interface, insuffisant pour les documents juridiques, les copies créatives ou tout ce où le ton et la nuance culturelle sont l'essentiel. Intégrez toujours une étape d'examen humain dans les projets clients.
La traduction DeepL affecte-t-elle le SEO ?
Le contenu traduit par machine qui n'a pas été examiné peut être signalé comme de faible qualité par les moteurs de recherche, particulièrement s'il semble peu naturel. Google a déclaré qu'il ne pénalise pas le contenu auto-traduit en soi, mais le contenu mince ou brouillé sera moins performant. Ma règle : examiner avant l'indexation, pas après.
Quelle est la meilleure façon de gérer les mises à jour de traduction quand le contenu source change ?
Suivez un hash de contenu (MD5 de la chaîne source suffit) à côté de chaque traduction dans votre base de données. Quand le contenu source est mis à jour, le hash change, ce qui signale la traduction comme obsolète. Votre pipeline rétraaduit alors uniquement les chaînes modifiées plutôt que la page entière. Cela réduit les coûts d'API et prévient les remous inutiles sur les chaînes qui avaient déjà été examinées par un humain.
---
L'API DeepL est l'un de ces outils qui a vraiment changé ma façon de cadrer les projets multilingues. Non pas parce qu'il élimine le besoin de jugement humain, mais parce qu'il déplace le travail de la traduction fastidieuse de première version vers un véritable examen éditorial. C'est une meilleure utilisation du temps de chacun, y compris du budget de votre client. Configurez-la avec soin, mettez en cache de façon agressive, intégrez l'étape de révision dès le départ, et elle vous servira bien.