DevRel : au carrefour du code, du produit et des gens. Le job tech qui change tout ?

Le DevRel ne vend rien. Il transmet. Il capte, éclaire, simplifie, connecte ! En bordure du marketing, au cœur du produit, les contours de sa mission tranchent avec les silos traditionnels. Ce n’est ni une mode, ni un gadget RH, mais un besoin structurel qui semble s'imposer peu à peu dans la plupart des organisations tech. 

Le DevRel, un rôle ou un métier ?

Pas de fiche de poste universelle. Pas de périmètre figé. « DevRel » désigne avant tout une posture, une dynamique, un rôle parfois assumé à plein temps, parfois en parallèle d’un poste de développeur.

Certains y voient un pont entre produit et communauté. D’autres parlent de porte-voix, d’intermédiaire, d’accélérateur de compréhension. Tous évoquent une même boussole : le partage.

« Je me lève le matin pour rendre la vie des développeurs plus simple ».

« Je n’explique pas les choses parce que je les sais, je les explique pour mieux les comprendre moi-même ».

Origine et émergence : de l’avant-vente au Developer Advocate

Initialement assimilé au rôle d’évangéliste technique, le DevRel moderne découle des mutations de l’écosystème dev : APIs, open source, cloud, DevOps.

Chez Salesforce ou Microsoft par exemple, les premiers DevRels créaient des ponts entre écosystèmes. 

Aujourd’hui, ils construisent des communautés, guident l’usage produit et facilitent l’adoption en interne.

Ainsi, un DevRel n’existe pas au singulier. Advocacy, support technique, création de contenu technique, retour produit, onboarding : il combine plusieurs casquettes.

Les 4 piliers invisibles du DevRel

Le partage : transmission, transparence, création de valeur

Tout commence là. Le partage. Pas le partage creux. Pas le « je poste un lien, j’ai fait ma part ».

Le vrai partage : celui qui traduit une galère en leçon, une erreur en documentation, une intuition en méthode reproductible.

Les formats varient :

• snippets de code sur GitHub

• tutoriels détaillés dans un README

• threads narratifs sur X avec capture d’écran et emojis bien dosés

• vidéos pédagogiques tournées en solo dans un coin de bureau

• talks dans un meetup local ou devant 1 000 personnes au Devoxx

Mais le but reste le même : rendre intelligible ce qui ne l’était pas encore.

Pas besoin d’être omniscient. Pas besoin non plus de réinventer la roue. Ce qui compte, c’est la clarté. L’intention. 

Certains DevRels excellent dans les articles ultra-techniques. D’autres vulgarisent en live coding, avec humour et autodérision. Les deux sont légitimes ! 

L’apprentissage continu : la posture du « non-expert utile »

Le DevRel passe sa vie entre deux états : apprendre et transmettre.

Il ne parle pas « d’autorité », mais « depuis le chemin ». Il creuse un sujet, se plante, recommence, documente.

Ce cycle fait de lui un repère pour la communauté. On peut résumer cette posture : apprendre à dire « je ne sais pas encore » renforce la confiance.

Ce « encore » fait toute la différence. Il ouvre l’espace du progrès, au lieu de figer la compétence.

L’empathie développeur : comprendre leurs douleurs, usages, besoins

Avant d’écrire une ligne de doc, le DevRel observe. Il navigue dans les tickets GitHub, les discussions Discord, les issues restées sans réponse depuis trois mois.

Une doc absconse, une API capricieuse, un SDK non maintenu. Ces détails, invisibles en interne, deviennent des murs côté utilisateur.

Le DevRel traduit ces signaux faibles en éléments concrets, exploitables par les équipes produit.

C’est une forme d’interprétariat technique, au service de l’expérience.

Le bonheur développeur : améliorer la DX et la satisfaction

Au fond, tout converge ici : faire en sorte que les développeurs prennent plaisir à utiliser un outil.

Pas juste qu’ils y parviennent. Qu’ils en parlent. Qu’ils le recommandent. Qu’ils aient envie d’aller plus loin !

La Developer Experience (DX) ne se limite pas à la vitesse d’intégration. Elle englobe notamment :

• la clarté de la documentation

• la logique des erreurs retournées

• la qualité des exemples

• la cohérence de l’API

• le soin apporté aux détails d’usage

Un DevRel s’attarde sur :

• la diminution des tickets d’assistance

• le temps moyen avant première requête

• le Net Promoter Score (NPS) technique

• la fréquence de réutilisation d’un SDK

Un profil tech… mais pas que : qui peut devenir DevRel ?

Un métier pour les « multipotentiels » tech

Le DevRel attire des profils singuliers, souvent hors-norme. Ni mono-spécialistes, ni touche-à-tout flous, ils naviguent avec aisance entre code, langage humain et dynamique de produit.

Ce sont des profils « multipotentiels » : curieux, transversaux, parfois inclassables. Leur force ? Combiner plusieurs registres sans s’y diluer.

Le DevRel émerge souvent à la croisée de trajectoires techniques et expressives.

Développeurs en quête de créativité et de contact

Certains développeurs saturent des sprints en boucle et du code sans contact humain. Ils ont soif de sens, de partage, d’impact visible. Pour eux, le DevRel permet d’ouvrir un nouveau terrain d’expression.

Ils conservent leurs compétences techniques mais les mettent au service de la pédagogie, de la transmission et du lien communautaire.

Communicants ou pédagogues devenus tech

L’inverse existe aussi : anciens journalistes, formateurs, enseignants passés par un bootcamp, une reconversion ou l’auto-formation.

Ils savent raconter, structurer, vulgariser. Le code devient pour eux un levier narratif. Quand ces profils maîtrisent les bases techniques, leur puissance pédagogique devient redoutable. Et quand ils découvrent GitHub et les conférences dev, ils se sentent souvent… chez eux.

Passionné d’open source et de communautés

Enfin, il y a les « community builders » organiques : ceux qui participent à des forums, rédigent de la doc, font du tri dans les issues. Ils n’ont pas cherché à être DevRel. Ils en incarnaient déjà les gestes. Leur sens du collectif, leur vigilance sur les détails, leur diplomatie les rendent essentiels.

C’est souvent à partir de ces contributions bénévoles que naît une première mission, puis un rôle à part entière.

Les défis souvent invisibles du rôle

Syndrome de l’imposteur : comment le transformer en levier ?

Un DevRel ne peut pas tout savoir. C’est inconfortable, parfois. Ce « non-savoir » assumé devient une ressource. Il crée une posture d’humilité et d’accessibilité. Il légitime les questions naïves.

Et il pousse à formuler les choses simplement — ce qui reste l’acte le plus difficile dans un environnement technique complexe.

Une identité professionnelle floue : entre tech, com et produit

Le DevRel évolue dans un triangle instable.

Trop technique pour les communicants. Trop tourné « utilisateur final » pour les ingénieurs backend. Trop axé communauté pour les chefs de produit orientés data. Il dérange les silos. Il traverse les frontières métiers. Il crée du lien, mais peine parfois à justifier sa place.

Cette ambiguïté n’est pas un défaut. Elle devient un atout… à condition de la cadrer. Car dans certaines structures, le DevRel subit ce flou. Il finit par être relégué à la production de contenu, perçu comme un influenceur technique « qui fait des tweets », ou comme un support amélioré.

La clé ? Cartographier son rôle de manière explicite, pour soi d’abord, puis pour les équipes. Définir ses zones d’impact, ses interlocuteurs, ses outils, ses métriques. Et les faire évoluer dans le temps.

C’est aussi une manière de se protéger contre les projections : non, le DevRel n’est pas « le commercial technique », ni « le rédacteur attitré », ni « le gourou GitHub ».

Il est une interface structurante entre la technologie et ceux qui l’utilisent.

Les 3 points clés à retenir :

• Le rôle de DevRel incarne une interface stratégique entre produit, technique et communauté, avec une posture hybride difficile à modéliser mais précieuse à structurer.

• Sa valeur réside autant dans la création de contenu utile que dans la remontée de feedbacks terrain et l'amélioration continue de l'expérience développeur.

• Ce métier attire des profils multipotentiels à l’aise dans l’apprentissage, la pédagogie et le relationnel, loin des trajectoires techniques classiques mais au cœur des enjeux tech actuels.