Contexte
Lemlist est un SaaS de sales outreach créé par Guillaume Moubèche en janvier 2018. C’est l’archétype de l’entreprise bootstrap (i.e. qui n’a pas levé de fonds) mais qui a tout de même connu une hyper-croissance avant d’atteindre une valorisation à 9 chiffres.
Pour assurer sa croissance, lemlist a étoffé ses fonctionnalités d’automatisation, notamment en développant une API (la condition sine qua non pour que les growth engineers puissent créer des automatisations complexes qui feront gagner du temps au XDRs).
Une API est un puissant levier de croissance car :
elle permet d’intégrer lemlist à n’importe quelle stack d’outils (on n’est plus limité par les intégrations natives que lemlist a eu le temps de développer)
elle donne envie aux ingénieurs de développer de nouvelles apps et automatisations, qui augmenteront l’utilisation du produit par les XDRs, la rétention, et, in fine, la customer lifetime value.
Problème
Leur documentation API a longtemps été désordonnée, confuse et incomplète. Et les conséquences étaient doubles :
les utilisateurs de lemlist étaient freinés dans leurs projets d’automatisation
les prospects étaient potentiellement refroidis en la comparant à celles des compétiteurs.
Lorsque Lucas Perret et moi en avons discuté en octobre 2025, le moment d’y remédier était arrivé. Il cherchait quelqu’un pour faire migrer et réécrire leur documentation développeur.
Objectifs
Lucas et moi nous connaissions déjà : il savait que j’avais des compétences techniques, une formation d’ingénieur solide, que j’avais déjà utilisé lemlist et que j’aimais écrire.
À juste titre, il a jugé que le projet se trouvait à l’intersection de ce que je savais faire, de ce que j’aimais faire, et, surtout, de ce dont il avait besoin.
Les objectifs que nous nous sommes fixés étaient de :
trouver une alternative à Postman (la solution sur laquelle était hébergée leur documentation)
migrer la documentation sur cette alternative
restructurer la documentation pour qu’elle intègre à la fois :
la référence API historique (complétée, plus agréable, mieux structurée, etc.)
des guides montrant comment implémenter les automatisations les plus courantes
harmoniser le terminologie et le formatage (url/query/body parameters, payloads, etc.)
ajouter des exemples de réponses à tous les endpoints de la référence API
écrire une documentation qui puissent également servir d’atout marketing
À nouveau, une documentation API est clé dans les délibérations d’un GTM engineer. En la lisant, on se fait vite une idée d’à quel point il sera simple et agréable de créer des automatisations avec un outil.
Il ne faut pas perdre ces délibérations face à la concurrence.
Et en vertu de ces objectifs, voici les livrables dont nous avons convenu :
un audit complet de la documentation actuelle incluant :
des propositions pour l’améliorer
un benchmark des hébergeurs que nous pourrions utiliser (Mintlify, Redocly, …)
la documentation développeur complète (référence API et guides utilisateurs)
un guide interne pour permettre à lemlist de la maintenir et la faire évoluer
Résultat
Voici la documentation développeurs de lemlist (j’y ai contribué pour la dernière fois le 3 décembre 2025).
Et voici ce que Lucas en a pensé :)
Soumettez le formulaire ci-dessous pour accéder à l’étude de cas détaillée. C’est une bonne feuille de route pour quiconque devrait créer / réviser / migrer une documentation API.
Vous y découvrirez notamment :
les conclusions de mon audit
le benchmark des différentes solutions de documentation API
l’importance d’un fichier OpenAPI
comment structurer une référence API
le lead magnet que nous avons disséminé dans les guides
comment j’ai saisi l’opportunité de faire ma propre promotion 🌝
le b-a-ba du SEO pour que la doc remonte dans les résultats de recherche
Pour vous aider à visualiser, voici à quoi ressemble une étude de cas détaillée : CaptainData — Outbound Growth.
À plus ✌
Bastien.
Comment j’ai procédé