Marketing auprès des développeurs : que proposer à côté d’une vidéo ?

Parmi les 5 680 personnes de l’analyse, 1 149 citent des créateurs de vidéos parmi les influences qui orientent leur choix de compétences et déclarent avoir utilisé de la documentation technique pour apprendre à coder. Un autre groupe de 603 personnes cite des créateurs de vidéos sans déclarer avoir appris avec de la documentation. Ces deux groupes forment le dénominateur du résultat de 65,6 % : 1 149 sur 1 752.^[1]

Le tableau complet est important. On compte aussi 2 677 personnes qui déclarent avoir appris avec de la documentation sans citer de créateurs de vidéos, et 1 251 qui n’ont coché aucune de ces deux réponses précises. Les personnes de ces deux derniers groupes ont pu regarder des vidéos ou utiliser de la documentation dans d’autres circonstances. Ne pas cocher une réponse ici ne prouve pas que l’on n’utilise jamais la ressource.

Dans l’ensemble du groupe ayant répondu aux deux questions, 67,4 % déclarent avoir appris avec de la documentation, soit 3 826 sur 5 680. Parmi les personnes qui ne citent pas de créateurs de vidéos, cette part est de 68,2 %, soit 2 677 sur 3 928. Le résultat de 65,6 % montre donc une coexistence, pas un recours plus fréquent à la documentation associé au fait de citer des créateurs de vidéos. Il ne permet pas d’affirmer qu’ajouter une vidéo augmentera l’utilisation de la documentation.

Pour une entreprise qui propose des outils de développement, la question utile est de savoir si la campagne laisse quelqu’un sans une ressource dont il pourrait avoir besoin. L’intérêt d’un public pour les créateurs ne justifie pas, à lui seul, d’omettre une référence écrite précise. L’étude ne détermine ni le budget à consacrer à chaque format, ni la pertinence d’un créateur particulier.

La question sur les influences demande ce qui aide à choisir les prochaines compétences techniques, en IA ou professionnelles à acquérir. Elle autorise jusqu’à trois sources. La question sur les méthodes d’apprentissage demande comment la personne a appris à coder durant l’année écoulée et permet plusieurs choix. L’une décrit une décision d’orientation ; l’autre, une activité d’apprentissage déclarée. Elles ne concernent pas nécessairement la même compétence, le même produit ou le même moment.^[3][4]

Un autre résultat rend cette distinction concrète. Parmi 1 491 personnes citant des créateurs de vidéos mais pas aussi la documentation dans leurs trois influences au maximum, 941 déclarent malgré tout avoir appris avec de la documentation, soit 63,1 %. La documentation peut apparaître dans une réponse sur la manière d’apprendre sans figurer dans une courte liste sur ce qu’il faut apprendre ensuite. Ce n’est pas un test visant à savoir si les répondants ont pensé à reconnaître le rôle d’une ressource.

Le pourcentage inverse répond encore à une autre question. Parmi les 3 826 personnes déclarant avoir appris avec de la documentation, 1 149 citent des créateurs de vidéos, soit 30,0 %. Les résultats de 65,6 % et de 30,0 % décrivent les mêmes 1 149 personnes. Aucun des deux ne doit être utilisé sans préciser le groupe qui lui sert de dénominateur.

Cette distinction peut améliorer un brief. Demandez ce que la démonstration doit aider à comprendre, puis quels détails doivent rester faciles à trouver ensuite ou indépendamment. Une page de référence ne devrait pas exiger d’avoir regardé une vidéo. Une vidéo ne devrait pas non plus promettre un exemple fonctionnel que les documents liés ne permettent plus de reproduire. Ce sont des choix pratiques de contenu, pas des résultats mesurés par l’enquête.

L’enquête est volontaire et ces questions sont facultatives. Nous avons identifié 11 071 personnes pour qui coder constitue une part principale du travail, qui déclarent avoir appris durant l’année écoulée et ont renseigné leurs méthodes d’apprentissage. Parmi elles, 4 952, soit 44,7 %, n’ont pas répondu à la question sur les influences dans le choix des compétences. Nous ne pouvons pas les classer parmi celles qui citent ou ne citent pas des créateurs de vidéos. Après exclusion des réponses indiquant notamment ne pas être en train de choisir quoi apprendre, il restait 5 680 personnes.^[1][2]

Ce groupe sans réponse est la principale raison de toujours rattacher le résultat à son dénominateur. Transformer les 65,6 % en une affirmation sur tous les développeurs, tous les participants à l’enquête ou toutes les personnes regardant une vidéo technique serait trompeur. L’enquête a surtout été diffusée par les canaux de Stack Overflow, ce qui influe également sur les personnes qui l’ont vue et ont choisi de la remplir.^[2]

Deux vérifications définies à l’avance modifient peu le recoupement. Conserver les réponses exploitables qui associent ne pas être en train de choisir à une influence précise donne 65,7 %. Restreindre le groupe principal aux personnes dont le statut professionnel principal est salarié ou indépendant donne 65,9 %. Ces vérifications portent sur ces choix particuliers ; elles ne suppriment ni les limites des réponses manquantes, ni celles du recrutement.

Une première étape utile consiste à ouvrir le document qu’un développeur recevrait aujourd’hui. Si un guide existant explique déjà la tâche montrée, la campagne peut simplement nécessiter un lien clair et une vérification du bon fonctionnement de l’exemple. Créer une page de campagne distincte peut ajouter un deuxième ensemble d’instructions à maintenir. Davantage de contenus ne signifie pas automatiquement davantage d’utilité.

Cherchez un manque précis avant d’ajouter quoi que ce soit. Une présentation des fonctionnalités peut expliquer la raison d’être d’un outil sans donner les données nécessaires pour l’essayer. Une référence technique peut énumérer tous les paramètres sans montrer d’exemple complet. Ces problèmes sont différents. Le premier peut demander un exemple détaillé ; le second, une brève explication de la façon dont les éléments s’articulent. Déterminez quelle question reste sans réponse, puis choisissez l’ajout utile le plus simple.

Le périmètre de la campagne compte aussi. Une vidéo présentant une idée technique peut renvoyer vers une explication ou un dépôt de démonstration. Une vidéo promettant de reproduire un résultat doit s’accompagner d’instructions à la hauteur de cette promesse. L’enquête ne choisit pas la bonne destination dans ces deux cas. Elle donne une raison de vérifier la ressource écrite dans le cadre de la campagne, sans supposer qu’un brief centré sur la vidéo règle à lui seul tout le travail de contenu.

Cette démarche aide aussi une petite équipe à établir ses priorités. Corrigez d’abord le prérequis manquant ou l’exemple obsolète. Commandez un autre format lorsqu’il répond à un besoin identifiable, plutôt que d’utiliser le pourcentage de recoupement comme objectif de volume de contenus à produire.

Imaginons une équipe fictive qui lance un outil permettant aux développeurs d’inspecter des événements webhook. Elle commande à un créateur une démonstration de quatre minutes : envoyer un événement d’exemple, examiner une requête en échec, corriger l’exemple et réessayer. Ce cas est inventé pour illustrer une méthode de préparation. Il ne suppose aucune réaction du public, aucun taux de conversion et aucun résultat de campagne.

La première version du brief indique seulement : montrer l’outil et ajouter un lien vers la page d’accueil. L’équipe rend la demande plus utile en précisant la tâche. Le créateur expliquera comment distinguer un contenu de requête mal formé d’un échec de transmission, à l’aide de données de test synthétiques. La démonstration a un objectif concret, auquel on peut comparer le document lié.

Un ingénieur produit prépare une page de référence avec le même contenu de requête d’exemple, les étapes de configuration, la version prise en charge et la sortie attendue. La page explique aussi l’erreur utilisée dans la démonstration. On peut la suivre sans ouvrir la vidéo. Le créateur peut ainsi expliquer l’intérêt des étapes de diagnostic au lieu de lire à voix haute chaque détail de configuration.

Avant la publication, un collègue qui n’a pas construit l’exemple suit les instructions écrites dans un environnement de test vierge. Si une commande échoue ou qu’un prérequis manque, l’équipe corrige l’exemple ou réduit la portée de sa promesse. Le collègue compare le résultat à la sortie attendue, au lieu de supposer que le simple fait d’avoir terminé les instructions signifie que l’exemple a fonctionné.

Le créateur vérifie ensuite que la description renvoie vers la référence prévue et que le résultat visible lui correspond. Si une version change plus tard, la personne responsable du produit doit explicitement mettre la page à jour et signaler toute différence importante avec la démonstration. Maintenir la cohérence entre les deux contenus est une mission plus concrète que demander à l’une ou l’autre équipe de rendre le contenu plus engageant.

Partez de la tâche du développeur. Décrivez en une phrase ce que la personne devrait pouvoir comprendre ou essayer. Pour la campagne fictive de webhooks : « Identifier pourquoi cette requête d’exemple a échoué et reproduire la requête corrigée dans un environnement de test. » Une promesse plus large, comme apprendre à utiliser l’ensemble du produit, demanderait un autre périmètre.

Précisez ce qui appartient à la vidéo. Nommez le problème, la décision que le créateur expliquera et le résultat qu’il montrera. Laissez-lui la liberté de l’explication tout en vous accordant sur les affirmations qui doivent correspondre au produit. Une démonstration utile peut mentionner un prérequis ou un cas que l’outil ne prend pas en charge.

Précisez ce qui appartient à la référence. Listez la configuration, les données d’exemple, la sortie attendue et les contraintes pertinentes. Donnez la destination exacte, son responsable et la version couverte. Une page d’accueil peut convenir à une présentation générale ; un exemple centré sur une tâche exige une destination qui réponde réellement à cette tâche.

Convenez d’une vérification lors de la remise des contenus. Le créateur contrôle la démonstration et la description ; le responsable produit vérifie les instructions et les affirmations. Demandez à un collègue d’essayer l’exemple, puis notez les corrections nécessaires. Le livrable réutilisable est un brief commun avec des responsabilités attribuées, pas simplement deux contenus qui mentionnent la même fonctionnalité.

Enfin, décidez quels retours justifieraient de modifier le contenu. Des questions répétées sur la configuration peuvent conduire à clarifier les prérequis. Un exemple inexact doit être corrigé même si la vidéo attire l’attention. Les vues, les visites de la référence et les essais réussis décrivent des actions différentes ; utilisez les éléments dont votre équipe dispose sans prendre l’un pour la preuve de l’autre.

Nous avons utilisé le fichier public complet de l’enquête Stack Overflow Developer Survey 2026, qui contient 30 903 réponses. La méthodologie officielle situe les réponses extraites entre le 23 juin et le 5 août 2026 et indique des réponses exploitables provenant de 169 pays. Le recrutement s’est fait principalement par le site, le blog et la liste de diffusion sur inscription de Stack Overflow. Cette analyse n’utilise pas de pondération d’enquête et décrit l’échantillon sans intervalles de confiance pour la population.^[1][2]

Les étapes d’éligibilité ont été fixées avant le calcul des résultats croisés. La question sur la création de code a identifié 23 234 personnes déclarant que coder constituait une part principale de leur travail. Parmi elles, 11 527 avaient appris à coder durant l’année écoulée, 11 071 avaient renseigné leurs méthodes d’apprentissage et 6 119 avaient aussi répondu sur les influences dans le choix des compétences. Nous avons exclu 344 personnes ayant uniquement indiqué ne pas être en train de choisir et 95 ayant combiné cette option avec une autre influence, pour aboutir à 5 680. Les réponses vides n’ont jamais été recodées comme des options non choisies.

La variable vidéo correspond à l’option « YouTube ou créateurs de vidéos » de CommunitySkills. La variable d’usage de documentation correspond à l’option de documentation technique de LearnCodeHow. Le choix Documentation comme influence reste une variable distincte. Nous avons séparé les réponses multiples publiées aux points-virgules et vérifié leur décodage par rapport aux 27 catégories des deux tableaux officiels ; tous les effectifs par catégorie et les deux bases de répondants concordaient.^[1][3][4]

La banque de questions archivée diffère des résultats publiés pour certaines autres options concernant les méthodes d’apprentissage. L’option de documentation utilisée ici concorde entre le questionnaire, le schéma et les résultats publics ; celle concernant les créateurs de vidéos aussi. Nous utilisons l’export public de l’éditeur et ne pouvons pas réappliquer indépendamment ses indicateurs internes de qualité des réponses, qui ne sont pas publiés. Ces deux points sont documentés dans les instructions relatives aux sources.

La vérification des réponses mixtes conserve les 95 réponses mixtes exclues, mais retire toujours celles qui indiquent uniquement ne pas être en train de choisir. La vérification du travail rémunéré retient seulement les statuts professionnels principaux salarié ou indépendant au sein du groupe principal. Une personne remplissant les autres critères et citant des créateurs de vidéos n’avait pas renseigné de méthode d’apprentissage. Selon que l’on considère cette personne comme ayant utilisé ou non de la documentation, la plage logique va de 65,54 % à 65,60 %. Cette plage étroite ne concerne que cette réponse manquante. Elle ne traite ni les 4 952 réponses manquantes sur les influences, ni la sélection volontaire des participants.

Des recherches antérieures décrivent déjà la combinaison de ressources d’apprentissage. L’enquête ponctuelle distincte menée par Stack Overflow en février 2026, par exemple, présentait des combinaisons associant IA et documentation. Notre apport est le croisement reproductible entre influence des créateurs et apprentissage avec la documentation dans cette édition annuelle. Nous ne traitons pas l’enquête ponctuelle comme une année de comparaison et ne prétendons pas découvrir que les formats peuvent se compléter.^[5]

Stack Exchange Inc. met la base de données source à disposition sous Open Database License (ODbL) 1.0 ; ses contenus individuels relèvent de la Database Contents License (DbCL) 1.0. Les téléchargements fournissent les résultats agrégés et la méthode complète de transformation, avec les liens vers les sources et les mentions de licence. Ils ne contiennent aucun enregistrement individuel ni identifiant de répondant. Les calculs et l’interprétation sont réalisés par Influence IQ, sans approbation de l’éditeur.^[6][7]