Le titre recouvre des postes très différents. Chez un éditeur d'API, de SDK ou d'outil pour développeurs, le developer advocate écrit des tutoriels et des exemples de code, présente le produit en meetup, répond sur GitHub ou Discord et rapporte à l'équipe produit ce qui bloque les utilisateurs. Il peut dépendre du marketing, du produit ou de l'ingénierie, et ce rattachement change la façon dont on le mesure. Tranchez ce point avant de publier l'offre.
Le niveau technique se vérifie en premier. Une liste de talks et un compte très suivi ne prouvent pas qu'une personne sait intégrer votre API, lire une trace d'erreur ou maintenir un exemple quand le SDK change de version majeure. Chez Google, les candidats DevRel passent des entretiens de code proches de ceux des développeurs, avec plus d'attention à la lisibilité. Demandez aussi un retour produit qui a abouti : un bug corrigé, une page réécrite, une option ajoutée après des plaintes.
Prévoyez un exercice en direct. Faites écrire un petit client de votre API, puis demandez de gérer une erreur 429 ou une pagination. Une personne incapable de sortir de son script de démo se repère vite. Le PDF ajoute un cas de 20 minutes sur une API dont les inscrits ne passent pas au premier appel.
Les outils et les livrables d'un developer advocate
API, SDK et exemples de code
Le developer advocate utilise le produit comme un client : il appelle l'API, installe les SDK, écrit des exemples dans les langages de la cible. Ces exemples vivent dans des dépôts publics et doivent tourner en CI. Un candidat qui ne sait pas faire marcher votre API en une heure aura du mal à la présenter.
Documentation et docs-as-code
Démarrage rapide, guides, référence générée depuis la spécification OpenAPI. La documentation est souvent rédigée en Markdown dans Git et relue comme du code. Le developer advocate y contribue beaucoup, parfois avec des rédacteurs techniques.
Démos, talks et live coding
Meetups, conférences, webinaires, vidéos et diffusions en direct. Le travail consiste à montrer du code qui résout un problème réel du public, avec un plan de secours si le réseau tombe. Demandez une captation ou faites présenter dix minutes en entretien.
Communautés en ligne
GitHub Issues et Discussions, Discord ou Slack, forums, tags Stack Overflow. Le poste demande de répondre vite, de modérer et de transformer les questions récurrentes en documentation. Les contributions externes aux SDK et aux exemples passent aussi par lui.
Boucle de retour vers le produit
Tickets avec reproduction, friction logs, synthèses des questions de la communauté. C'est ce qui sépare un developer advocate d'un profil purement marketing. Faites raconter un retour qui a changé quelque chose dans le produit.
Mesure de l'adoption
Inscriptions attribuées aux contenus, délai jusqu'au premier appel réussi, activation, rétention, intégrations publiées. Les vues et les abonnés comptent moins. Vérifiez que le candidat sait relier ses actions à ces indicateurs et connaît les limites de l'attribution.
Documentation lue par les assistants IA
Beaucoup de développeurs découvrent une API par un assistant de code. Des éditeurs publient une version texte de leur documentation, un fichier llms.txt ou un serveur MCP pour que ces outils proposent des appels corrects. Le sujet entre peu à peu dans les fiches de poste DevRel.
Le poste existe surtout chez les éditeurs dont les clients sont des développeurs : API, plateformes cloud, bases de données, outils d'observabilité ou de paiement. Les offres publiées en France sont rares. Certaines sont ouvertes en télétravail sur plusieurs pays européens, avec une partie du travail en anglais. Selon le rattachement, on parle de developer advocate, de DevRel engineer, d'évangéliste technique ou de community engineer. Les offres demandent en général plusieurs années de développement ou d'exploitation, des contenus publics consultables et une aisance en langage de script. Le travail se partage entre code, contenus, communauté et retours produit, dans des proportions à fixer dès l'offre.
Six compétences DevRel à établir en entretien
- Maîtrise de l'API, des SDK et du code d'exemple
- Documentation et tutoriels qui tiennent dans le temps
- Démos et prise de parole technique
- Animation et modération de communauté développeurs
- Retours produit argumentés et suivis
- Mesure de l'adoption et priorités du programme
Du premier exemple de code au bilan de six mois
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
On vous donne notre API et une heure. Qu'écrivez-vous pour montrer à un développeur qu'elle règle son problème, et que vérifiez-vous avant de le publier ?
Une bonne réponseUn exemple court qui tourne de bout en bout : authentification, un appel utile, la gestion des erreurs 401 et 429, la pagination si la réponse est longue. La clé d'API passe par une variable d'environnement, le README donne les prérequis et la version du SDK. Avant publication, la personne relance l'exemple sur une machine vierge ou dans un conteneur, et l'ajoute à la CI pour qu'il casse visiblement le jour où l'API change.
Signal d'alerteUne démo qui ne marche que sur son poste, une clé copiée en dur dans le code, ou un exemple qui ne traite que le cas où tout se passe bien.
Question 2 · senior
Une version majeure du SDK casse la moitié des exemples que vous avez publiés. Comment organisez-vous la transition pour les développeurs ?
Une bonne réponseIl recense d'abord ce qui est touché : exemples, tutoriels, articles, vidéos. Les exemples tournent en CI contre chaque version supportée, ce qui donne la liste exacte. Ensuite un guide de migration avec le code avant et après, des avertissements de dépréciation dans la version précédente, des notes de version claires et une documentation versionnée. Le profil senior a parlé du changement avec l'équipe SDK avant la sortie, en s'appuyant sur le versionnement sémantique.
Signal d'alerte« On corrige au fil des signalements », ou aucune idée de ce qu'implique une version majeure en versionnement sémantique.
Question 3 · confirmé
Un tutoriel fait beaucoup de vues, mais la plupart des lecteurs abandonnent à l'étape trois. Comment trouvez-vous la cause ?
Une bonne réponseIl refait le tutoriel lui-même sur un environnement neuf, en suivant le texte à la lettre. Il croise avec les données : temps passé par section, questions posées sur le forum ou Discord, erreurs renvoyées par l'API aux comptes récents si l'équipe y a accès. Les causes fréquentes sont un prérequis non dit, une version de bibliothèque qui a changé ou une étape d'authentification mal expliquée. Il corrige, puis mesure de nouveau.
Signal d'alerte« On fait une vidéo en plus », sans avoir relancé le tutoriel. Ou un contenu jamais retesté depuis sa publication.
Question 4 · junior à confirmé
Sur le Discord de la communauté, la même question revient dix fois par semaine. Que faites-vous ?
Une bonne réponseIl écrit une réponse de référence dans la documentation ou la FAQ et y renvoie. Puis il cherche pourquoi la question revient : message d'erreur obscur, page de doc introuvable, comportement surprenant de l'API. Si l'API est en cause, il ouvre un ticket produit avec les exemples. Il vérifie ensuite que la question baisse. Il ne porte pas tout le support seul : règles de canal, réponses épinglées, membres actifs qui aident.
Signal d'alerteRépondre à la main à chaque fois sans chercher la cause, ou laisser les questions sans réponse.
Question 5 · tous niveaux
Racontez un retour de développeurs que vous avez porté jusqu'à un changement dans le produit.
Une bonne réponseUn cas précis : combien de signalements, venus d'où, quel blocage. La forme du retour compte autant que le fond : un ticket avec une reproduction, l'effet mesuré sur l'activation ou le support, une proposition de correction. Il cite l'interlocuteur (le product manager, l'équipe API), le résultat (corrigé, reporté ou refusé avec une raison) et la façon dont il a prévenu la communauté une fois le changement livré.
Signal d'alerte« J'ai remonté beaucoup de retours » sans exemple. Ou une posture de porte-parole qui exige sans données ni reproduction.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
DevRel : ce que les recruteurs demandent avant d'ouvrir le poste
Developer advocate, DevRel engineer, évangéliste technique : quelle différence ?
Les titres se recouvrent souvent. Le developer advocate représente le produit auprès des développeurs et les développeurs auprès de l'équipe produit. Le DevRel engineer passe plus de temps sur le code : SDK, exemples, intégrations. L'évangéliste technique est un intitulé plus ancien, centré sur la prise de parole. Le community manager développeurs anime la communauté sans forcément coder. Décrivez la répartition attendue entre code, contenus et communauté plutôt que de vous fier au titre.
Quel niveau de code exiger d'un developer advocate ?
Assez pour écrire seul une intégration propre avec votre API, la déboguer en direct et la maintenir quand le SDK change. Il n'a pas à concevoir l'architecture du produit. Pour un poste orienté SDK ou intégrations, visez le niveau d'un développeur confirmé dans le langage cible. Pour un poste orienté contenus, la lisibilité du code et la justesse des explications comptent plus que la vitesse.
Comment évaluer un portfolio de talks et d'articles ?
Choisissez deux contenus et posez des questions précises : pour quel public, avec quel objectif, quel résultat. Vérifiez que le code des articles tourne encore et que les explications sont justes. Un portfolio fourni ne remplace pas un exemple de retour produit abouti. À l'inverse, un profil sorti du développement avec peu de contenus publics peut convenir s'il écrit bien et explique clairement en entretien.
Quel exercice donner à un developer advocate en entretien ?
Un test technique court en direct plutôt qu'un long devoir à la maison : faire écrire un client de votre API, puis le prolonger hors du cas nominal. Ajoutez une lecture critique de votre propre documentation, en demandant ce qui bloquerait un nouveau développeur. Une présentation de dix minutes sur un sujet de son choix complète l'ensemble. Fixez à l'avance ce qui compte dans la notation.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
