Lancement du TranslatePress : du concept au produit fini

Par Cristian

Dernière mise à jour : 1er septembre 2025

Lorsque vous lancez un nouveau projet, il y a toujours une effervescence d'excitation, d'espoir, de soulagement, mais aussi la peur de l'échec et de la déception.

C'est quelque chose que j'ai vécu pour tous les projets dont j'ai fait partie au cours des 9 dernières années, au point que j'attends activement avec impatience le premier lancement raté.

Rien n'illustre mieux ce qui précède que les commentaires que nous avons reçus des utilisateurs qui utilisent actuellement notre TranslatePress greffon.

Espoir : Nous utilisons déjà votre plugin gratuit. Nous aimerions l'acheter plus tard.
Peur de l'échec : Si ça fonctionne avec le plugin qui gère la réservation sur notre site.

Ensuite, il y a le nombre abyssal d'installations actives après avoir envoyé plus de 7 000 e-mails à d'anciens clients. Moins de 10 pour les deux premières semaines.

Mais il ne s'agit pas de l'histoire de quelque chose qui ressemble à un lancement de produit raté (nous y reviendrons).

Je vais plutôt remonter à décembre 2016 et commencer par vous expliquer presque tout ce que nous avons vécu au cours des huit derniers mois pour le lancement de TranslatePress, depuis le concept initial jusqu’à la création d’un tout nouveau plugin qui vous permet de traduire un Site web WordPress en plusieurs langues.

Je vais passer par :

pourquoi un nouveau plugin de traduction et comment nous avons eu l'idée
allouer des ressources de développement et décider d'un calendrier
le dépassement du délai de près de 2,5 fois et les raisons de celui-ci
créer rapidement un logo et quelque chose qui ressemble à une marque
décider de la manière dont le plugin sera monétisé
implémentation d'un tout nouveau site, configuration des paiements et des licences
lancement de la version bêta du plugin et travail sur une nouvelle fonctionnalité
marketing
conclusions

Construisons un plugin, qu'ils disaient ! Ce sera amusant, qu'ils disaient !

Comme chaque fin d'année, nous avons une réunion avec le reste de l'équipe de Cozmoslabs ce qui a fonctionné cette année-là, ce qui a complètement échoué et ce que nous attendons avec impatience pour l'année prochaine.

Mon collègue Razvan Mocanu voulait travailler sur un tout nouveau projet. Un nouveau plugin. Nous avons donc pris note mentalement, sommes partis en vacances de Noël et sommes revenus en janvier avec une seule bonne idée sur laquelle nous avions vraiment envie de travailler : un plugin de traduction pour WordPress que tout le monde peut utiliser.

Bien que cela semble quelque peu arbitraire, ce n'est pas vraiment le cas :

en tant que développeurs de plugins, nous avons dû faire face à des plugins de traduction dès le premier jour (pour l'instant, nous prenons en charge WPML dans tout notre plugins)
avant de passer au développement de plugins, nous étions une agence de développement sur mesure qui mettait en œuvre WPML pour divers clients (cela fonctionnait pour nous en tant que développeurs, presque jamais pour le client final)
nous n'aimions vraiment pas le flux de travail de traduction de presque tous les plugins de traduction sur le marché. (Non visuel, hors contexte, trouvé à plusieurs endroits)
nous savions que nous ne voulions pas faire un clone de WPML ou travailler avec des installations Multisite

Le seul autre plugin existant sur le marché qui faisait quelque chose de différent était WeGlot. Une implémentation de type Logiciel en tant que service qui propose une traduction automatique et manuelle. En gros, la traduction de votre site est chargée depuis leurs serveurs.

De la combinaison des extensions et des idées ci-dessus, nous avons élaboré un concept similaire à WeGlot, mais assez différent dans sa mise en œuvre :

Traduisez la page entière. Fini les allers-retours entre l'éditeur, les interfaces de traduction de chaînes ou les plugins mal traduits. Vous pouvez désormais traduire la page finale avec un support complet pour WooCommerce et les constructeurs de sites.

La principale différence réside dans l'implémentation:

prise en charge des chaînes dynamiques ( chaînes gettext )
tout est stocké localement, dans votre base de données (vous êtes propriétaire de vos traductions)
un plugin GPL (accès au code source au cas où vous auriez besoin de quelque chose de différent)
le désir de faire fonctionner notre plugin avec n'importe quel plugin ou thème WordPress et non l'inverse, où les développeurs doivent ajouter un support pour les plugins de traduction

Estimations de développement

En janvier, mon collègue Madalin Ungureanu a déclaré avoir testé le cœur du plugin, une classe d’analyseur DOM en PHP, afin de voir si nous pouvions l’utiliser. Cela fonctionnait plutôt bien : nous pouvions effectuer des recherches et des remplacements de chaînes de caractères dans la base de données sans ralentir le site de test ; nous avons donc décidé de lancer le projet. Razvan devait être le développeur principal et serait chargé de livrer les versions alpha et bêta, après quoi nous allions allouer davantage de ressources au projet. Bien que ce ne fût pas l'idéal, c'était tout ce que nous pouvions faire sans embaucher davantage de personnel.

3 mois. Sortons une version alpha/bêta en avril. En juillet, nous avons commencé les tests en interne et avons fait pression pour un lancement bêta. Le 31 juillet, nous avons rendu la version bêta disponible au téléchargement. Le lancement final a eu lieu le 4 septembre, soit plus de 5 mois de retard sur nos prévisions.

Je m'attends également à ce que les tâches de développement logiciel prennent plus de temps que prévu.

Tout comme pour le lancement lent, j'en suis également venu à m'attendre à ce que les tâches de développement logiciel prennent plus de temps que prévu.

Il y a quelques exceptions à la règle, mais c'est généralement à la fin d'un cycle de développement, lorsque le problème était déjà bien défini et compris, ne nécessitait pas de recherches supplémentaires et qu'il ne restait plus qu'à écrire le code.

Alors, pourquoi cela a-t-il pris plus de temps que prévu ?

Il est évident que nous avons sous-estimé le temps nécessaire. Nous ne savions vraiment pas combien de temps cela prendrait.
Le délai de trois mois a été imposé davantage pour des raisons pratiques. Ne poussez pas le projet dans la période des vacances d'été. (ce que nous avons fait)
Razvan est toujours un développeur junior et c'fût son premier grand projet dans l'entreprise. Bien qu'il y ait eu pas mal de discussions concernant l'orientation du développement et la mise en œuvre, très peu de code réel n'a été écrit par quelqu'un d'autre de l'équipe lors des premières étapes du projet. La progression a donc été lente.
Une fois que j'ai commencé à tester le plugin en juin, rien n'fonctionnait. Sur mon installation en tout cas. Alors que Razvan a essayé de généraliser autant que possible le problème (remplacement rapide de chaînes), il nous est rapidement apparu clairement qu'il y avait beaucoup plus de cas limites que nous ne l'avions réalisé et prévu dans le budget.

Conception de logo sur le pouce

Pendant que le plugin était en cours de développement, j'ai concentré mon attention sur la conception d'un nouveau logo et d'une nouvelle palette de couleurs pour notre futur site web.

Je ne suis absolument pas graphiste, mais je me débrouille pour manipuler des pixels dans Photoshop. Je connais mes limites et je m'en sors en combinant des carrés, des rectangles et des cercles pour arriver à quelque chose de correct. Pas extraordinaire, mais correct. J'ai donc bloqué quelques heures et j'ai préparé 4 propositions (allant de puériles à passable) que j'ai montrées au reste de l'équipe.

Nous avons choisi le dernier et avons avancé avec conception de site web.

Dans l'ensemble, il y avait probablement 3 à 4 jours de travail effectif répartis sur quelques mois pour obtenir tous les graphismes et le design dont nous avions besoin pour le lancement. Le thème était un clone du même thème personnalisé que nous avons utilisé sur www.cozmoslabs.com nous avons donc passé le moins de temps possible à le sortir.

Bien que le design soit très important, le sortir avec un investissement minimal l'était encore plus. Le design de Cozmoslabs a été le fruit de 4 mois de travail avec un designer (avec beaucoup d'aller-retours) et de deux mois supplémentaires pour l'implémenter dans son intégralité. Nous ne pouvions tout simplement pas nous le permettre à ce stade. Nous avons donc fait quelque chose de correct et nous avons progressé.

Monétisation

Nous avons décidé très tôt qu'il y aurait du gratuit et du Versions Pro. Nos propres expériences passées ainsi que celles d'autres développeurs de plugins de la communauté WordPress ont clairement montré que c'était la voie à suivre.

Ce qui n'était pas si clair, c'est comment nous devrions différencier les versions. Les éléments que nous avons considérés comme faisant partie des versions Pro étaient :

traduction de types de publication personnalisés;
plusieurs langues;
API Google Translate ;
Module SEO (traduction du slug, du titre de la page et de la description).

Ce sur quoi nous avons finalement décidé, c'est d'inclure le Module SEO et Plusieurs langues dans les versions Pro + une différenciation basée sur le nombre d'installations actives.

Outre cela :

chaque niveau de tarification est d'une durée d'un an, avec renouvellement automatique ;
Les versions Pro contiennent uniquement les extensions Avancées. La version gratuite sera donc toujours nécessaire.

Lancement de TranslatePress – Nouveau site, configuration des paiements et des licences

Pour vendre notre nouveau plugin, nous avons essayé de le garder aussi simple que possible, nous avons donc utilisé Easy Digital Downloads et Digital Licenses for EDD.

Malheureusement, pour que notre installation fonctionne, nous avons eu besoin de travail sur mesure :

notre passerelle de paiement Avangate (codée sur mesure car l'API d'Avangate est tout simplement bizarre)
renouvellements automatiques d'Avangate (nous ne pouvons pas utiliser EDD pour cela mais quelque chose codé sur mesure)
licences numériques pour un produit de type “ Bundle ” afin qu'une seule licence fonctionne sur tous les modules complémentaires du “ Bundle ” (cela ne fonctionne pas avec EDD)

Nous voulions utiliser le module complémentaire All Access Pass pour EDD qui résolvait les licences numériques pour les lots, mais cela n'a pas fonctionné pour nous parce que :

Si vous possédez un Pass Tout Accès, vous ne pouvez pas en acheter un autre, seulement prolonger la période de licence.
cela a cassé nos renouvellements automatiques personnalisés (en raison de la façon dont Avangate gère les renouvellements automatiques)
cela a également cassé les mises à niveau car, encore une fois, les mises à niveau sont personnalisées en raison d'Avangate.

Nous avons donc fini par coder sur mesure un module complémentaire pour EDD qui fonctionne un peu comme All Access Pass (le code est fondamentalement tiré du module complémentaire), mais sans la partie All Access 🙂

À part cela, le thème a été recyclé de Cozmoslabs comme mentionné précédemment et nous avons utilisé le nôtre Profile Builder Pro extension pour les fonctionnalités de connexion, de modification de profil et de réinitialisation du mot de passe.

Lancement de la version bêta

Une façon de créer une dynamique pour un produit est le lancement d'une version bêta. Bien qu'il y ait d'autres raisons à un lancement bêta (signalement de bugs), ce que j'ai vécu avec d'autres extensions par le passé, c'est que Le principal avantage est la possibilité de parler de votre produit même s'il ne fonctionne pas encore. 🙂

Bien qu'assez superficiel dans sa démarche, c'est juste un autre outil marketing que l'on peut utiliser. Et en prime, nous avons également reçu quelques rapports de bugs/fonctionnalités pertinents qui ont mis en évidence qu'il nous manquait un élément crucial avec la version bêta : Il n'y avait pas de prise en charge des champs gettext.

La prise en charge des champs gettext était l'une des grandes fonctionnalités que nous voulions introduire APRÈS le lancement. Cependant, en jouant de plus en plus avec le plugin et en écoutant ce que nos utilisateurs bêta avaient à dire à ce sujet, nous avons pris notre courage à deux mains et avons commencé à travailler sur cette fonctionnalité juste après le lancement de la version bêta du plugin.

C'est l'une des plus grandes erreurs que nous aurions pu commettre d'un point de vue du développement et l'une des raisons pour lesquelles nous avons mis si longtemps à lancer la version 1.0. Nous avons retardé la prise en charge de gettext parce que c'était difficile à mettre en œuvre.

Une drôle d'histoire sur nos débuts est qu'après le lancement de la version bêta, nous avons eu une coupure de courant d'une heure au bureau. Pendant que j'attendais que le courant revienne, je me suis mis à nettoyer mon clavier. Il n'y avait rien de mieux à faire de toute façon, alors j'ai pris une photo du clavier, j'ai retiré toutes les touches, et j'ai procédé à leur nettoyage une par une avec un peu d'alcool à friction et un chiffon.

Et pendant les 2 heures suivantes, j'ai nettoyé mon clavier et créé une carte mentale de l'implémentation de gettext dans WordPress, de la manière dont notre plugin traduisait les chaînes de caractères et de la façon dont nous pouvions combiner les deux, sans créer de problèmes de performance par la suite.

Après cela, j'ai eu une brève discussion avec Madalin concernant gettext, nous avons décidé de le faire maintenant, avant le lancement de la version 1.0, et il s'est mis au travail.

Cette histoire comporte deux enseignements principaux :

C'est une mauvaise idée de retarder des fonctionnalités compliquées sans bonne raison. Nous savions que ce serait compliqué, c'est pourquoi nous avons attendu si longtemps pour le faire ;
alors que les 2 heures passées à réfléchir à gettext n'ont absolument rien donné en termes de temps de développement réel (il a fallu 1 mois de travail à Madalin pour que ça fonctionne et il en est maintenant à son deuxième mois à gérer wp_ajax et gettext), c'était infiniment mieux que de ne pas y penser du tout. C'était ce dont nous avions besoin pour décider et nous débloquer.

Pour promouvoir la version bêta, nous :

rédigé un article bêta également optimisé pour le référencement naturel sur le mot-clé “WordPress en plus de langues”(inutile d'écrire plus de 2000 mots sans espérer un peu de trafic SEO à l'avenir.);
envoi d'une newsletter à nos clients actuels de Cozmoslabs concernant le nouveau plugin ;
disposait de formulaires “ Inscription à la bêta ” en bonne et due forme sur le site web de TranslatePress ;
deux semaines après le lancement de la version bêta, nous avons demandé aux 100 personnes inscrites de nous faire part de leurs commentaires (pour cela, nous avons utilisé Mailchimp) ;
Pendant encore deux semaines, nous avons diffusé des publicités Facebook qui ont augmenté notre nombre de bêta-testeurs à 160.

Version 1.0

Il nous a fallu un mois de développer → test → réparer cycles pour faire fonctionner l'implémentation gettext pour les chaînes rendues par PHP (modèles de pages normaux).

Nous n'avions toujours pas de prise en charge de gettext pour les appels wp_ajax, mais Il était important de lancer maintenant et non plus tard:

si nous avions tardé à tout finaliser, nous aurions perdu du temps pour le marketing (ou du moins pour voir ce qui fonctionne et ce qui ne fonctionne pas). S'il n'y a pas de produit, nous ne pouvons pas parler du produit ;
nous aurions pu perdre l'opportunité de parrainer WordCamp Bucarest cela se produit en octobre ;
Une fois le site web, la passerelle de paiement, les licences, le support et la documentation configurés, il ne nous reste plus qu'à travailler SUR le produit.

Marketing

Depuis le lancement de la version bêta, nous avons commencé à penser à la commercialisation du module.

Un modèle économique freemium signifie que nous dépendons d'un grand nombre d'utilisateurs gratuits et d'installations actives.

Avec un nouveau plugin, c'est beaucoup plus difficile que vous ne le pensez, en particulier avec le nouveau répertoire WordPress qui prend en compte les installations actives, les avis, le nombre de questions traitées sur les forums et d'autres éléments quantitatifs sur lesquels nous n'avons aucun contrôle.

Nos efforts ont donc été orientés vers le fait de nous présenter devant le plus grand nombre possible d'administrateurs WordPress :

nous avons ajouté une promotion croisée dans nos autres plugins (TranslatePress permet de traduire nos autres plugins, c'est pourquoi nous l'avons ajouté à notre section « Plugins recommandés ») ;
j'ai ajouté le téléchargement gratuit sur la page de compte de tous nos clients chez Cozmoslabs ;
entrato en contact avec ThemeIsle pour ajouter TranslatePress à la liste des plugins recommandés, car il fonctionne très bien pour traduire leurs thèmes complexes (nous utilisons Hestia pour notre site de démonstration);
parrainer WordCamp Bucarest et avoir l'occasion de parler à des utilisateurs potentiels en personne.

Tous ces efforts sont particulièrement importants au début pour gagner un peu de visibilité, afin que TranslatePress apparaisse dans les résultats de recherche de WordPress.org.

Nous avons essayé d'être le moins possible des pollupesteurs, si tant est que ce soit possible. Nous n'avons pas utilisé de notifications visibles sur toutes les pages d'administration et nous n'avons pas harcelé nos clients actuels de newsletters (seulement deux pour le lancement de la bêta et de la version 1.0).

Futurs plans marketing :

nous prévoyons de créer des tutoriels pour de nombreux thèmes populaires et sur la façon de les traduire (merci Ionut);
poursuivre nos efforts de sensibilisation auprès des développeurs de plugins et de thèmes. Nous voulons ajouter un support pour les plugins, et non que les plugins aient à ajouter un support pour nous ;
Le marketing de contenu multilingue est difficile parce que nous ne serons pas bien classés dans les moteurs de recherche. Pas au début en tout cas. Donc, bien que nous soyons actifs sur ce front, ce n'est pas très important pour nous pour l'instant.

Conclusions from our TranslatePress launch

The main thing I want to highlight about this 8 month process, is that it’s not the end of the line. Lack of interest at the beginning is normal. Little to no downloads are normal. Little to no feedback is normal.

Instead of worrying about all this, I’ve come to see initial launches for what they really are: structure on which the company can build the product and market it in the future.

The real success or failure comes at a much later time.

It’s even been comical for me to see how bad initial launches are and to make bets with the rest of the team that are almost always way more optimistic 🙂

Finally, here’s a list of the things we’ve learned about our TranslatePress launch in this past 8 months:

launches as building up the structure of the project. Once out you can work on marketing and improving the product;
don’t delay thinking about complicated parts of the project. You can choose to include them or not in Version 1.0, but never, ever NOT think about them;
ask feedback from other people from the community. I’ve had some really interesting discussions with the PostStatus community (technical), with local WordPress people who implement multilingual websites (about features), with actual users (they loved the easy-to-use interface, if only the plugin worked for all strings 🙂 ), with other WordPress product people (marketing). Future features, technical decisions, and marketing are influenced by this feedback;
spend the needed amount of time on important features. We’ve spent a lot of time on the gettext implementation and continue to do so. It’s the one thing that makes the entire plugin so versatile, so it has to work;
unless you’re selling actual design work, don’t spend a lot of time on the website design. Focus instead on making the content clear, without fancy words, and structured so it’s not overly complicated for someone non-technical. If you’re not sure where to start, just go over to AffiliateWP and steal their content structure. No one will notice;
everything you can set up and forget should be done early on. If you can’t use off-the-shelf tools to sell your plugin, custom code them now if you know how to. With the infrastructure in place, we can 100% focus on the plugin for the next year or more, without worrying about changing the pricing structure, renewals, accounts, etc.

So this is the beginning of our TranslatePress adventure.