Une recruteuse prend des notes face à un candidat lors d'un entretien d'embauche dans un bureau

Entretien technique développeur : les étapes, 18 questions et un exercice corrigé

L’essentiel en une minute

Un entretien technique développeur n’est presque jamais un examen unique : c’est une suite d’étapes, de la présélection téléphonique au live coding, et chacune se prépare différemment. Ce guide s’adresse aux développeurs juniors et confirmés qui postulent en France.

Il repose sur des sources publiques consultées le 1er novembre 2026, sans test auprès de recruteurs ; seul le code de l’exercice corrigé a été exécuté.

Points clés

  • Selon l’Apec, 71 % des entreprises ayant recruté au moins un cadre en 2025, tous métiers confondus, ont utilisé une présélection téléphonique et 48 % des tests. Préparez-vous aux deux.
  • Les questions techniques portent sur les fondamentaux : égalité en JavaScript, méthodes HTTP, jointures SQL, Git, Docker, sécurité, complexité. Les 18 réponses modèles ci-dessous tiennent en quelques lignes chacune.
  • En live coding, on évalue autant votre raisonnement que votre code : reformulez, donnez une solution simple, puis améliorez-la à voix haute.
  • Le Code du travail impose que les méthodes de recrutement vous soient annoncées à l’avance et qu’elles soient pertinentes pour le poste.
  • L’IA n’est pas interdite partout : Canva exige son usage dans certains entretiens, Anthropic l’interdit sauf indication contraire. Demandez toujours la règle.

Les étapes d’un recrutement de développeur en France

Aucune source ne fixe un modèle unique, mais le cours d’OpenClassrooms sur les tests techniques décrit une séquence type : tri du CV, appel de qualification non technique, tests techniques, puis entretien final avec un fondateur ou le futur manager, où le salaire est discuté (OpenClassrooms, consulté le 1er novembre 2026).

Les chiffres français les plus récents viennent du baromètre 2026 de l’Apec, mené auprès de 1 150 entreprises ayant recruté au moins un cadre en 2025, tous métiers confondus (Apec, Pratiques de recrutement de cadres 2026, mai 2026, PDF hébergé par la Banque des Territoires).

Ce qu’il relève pour 2025 :

  • La présélection téléphonique : 71 % des entreprises y ont recouru pour au moins un recrutement de cadre.
  • Les tests de recrutement : 48 % en ont utilisé, et 29 % de l’ensemble des entreprises ont eu recours à des mises en situation professionnelle.
  • Les compétences comportementales : 96 % des entreprises les jugent au moins aussi importantes que les compétences techniques.
  • La durée : le dernier recrutement de cadre a pris en moyenne 12 semaines, un niveau stable depuis deux ans.

Depuis 2019, la présélection téléphonique progresse et les tests restent proches de la moitié des entreprises, selon le graphique de la page 8 du rapport.

Graphique en courbes de l'Apec, utile pour préparer un entretien technique développeur : présélection téléphonique de 58 % en 2019 à 71 % en 2025, tests de recrutement de 52 % en 2019 à 48 % en 2025

Les étapes les plus courantes, avec une durée seulement quand une source la donne :

Étape Ce qui est évalué Durée indiquée par une source Qui vous reçoit
Présélection téléphonique Motivation, parcours, adéquation au poste, salaire attendu Non précisée Recruteur ou RH
Discussion technique Fondamentaux, projets passés, capacité à expliquer Généralement 30 à 45 minutes, jusqu’à 1 h 30 (OpenClassrooms) Un ou deux développeurs
Test technique en ligne ou à la maison Code fonctionnel, lisibilité, tests Fixée par l’entreprise Correction par l’équipe
Live coding Raisonnement, communication, gestion des cas limites Fixée par l’entreprise Un ou deux développeurs
Conception de système (profil confirmé) Découpage, compromis, montée en charge Fixée par l’entreprise Développeur senior ou architecte
Entretien final Adéquation à l’équipe, projet, rémunération Non précisée Manager ou fondateur

Préparer chaque étape de l’entretien technique développeur

Chaque étape d’un entretien technique développeur teste une chose différente, donc la préparation change d’une étape à l’autre.

La présélection téléphonique. Préparez une présentation de deux minutes : ce que vous savez faire, un projet concret, ce que vous cherchez. Ayez votre fourchette de salaire prête : notre comparatif des salaires des développeurs en France aide à la fixer. Votre CV doit raconter la même histoire ; pour sa structure, voir notre guide du CV développeur junior.

La discussion technique. Relisez vos propres projets : on vous demandera pourquoi vous avez choisi telle base de données ou telle bibliothèque. Un portfolio de développeur à jour sert de support. Le chapitre d’OpenClassrooms sur les discussions techniques conseille de faire des schémas et d’admettre ce que l’on ne sait pas.

Le test technique et le live coding. Avant un test technique, entraînez-vous sur des exercices courts, chronométrés, en parlant à voix haute. Révisez les bases de votre langage : notre parcours pour apprendre JavaScript et notre cours de SQL pour débutants couvrent la plupart des questions ci-dessous.

La conception de système, pour un poste confirmé. On vous demande de concevoir un service (raccourcisseur de liens, fil d’actualité, file de tâches). Une démarche claire compte plus que la bonne réponse :

  1. Clarifier les besoins et le volume attendu.
  2. Définir l’API et le modèle de données.
  3. Dessiner les composants : serveur, base, cache, file de messages.
  4. Repérer le point qui cassera en premier et proposer un compromis.

L’entretien final. Préparez deux ou trois situations vécues : un bug difficile, un désaccord technique, une erreur corrigée.


18 questions techniques classiques et leurs réponses

Ces questions techniques couvrent les bases d’un poste web. En entretien, donnez la réponse en une phrase, puis un exemple.

JavaScript

1. Quelle différence entre == et === ? === compare sans conversion de type ; == convertit d’abord les opérandes. Ainsi '1' == 1 vaut true, mais '1' === 1 \1\2, égalité stricte](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Operators/Strict_equality)).

2. var, let et const ? var a une portée de fonction ; let et const ont une portée de bloc. const interdit la réaffectation de la variable, pas la modification de l’objet qu’elle contient (MDN, let). Exemple classique : for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)); affiche trois fois 3, car les trois rappels partagent la même variable ; avec let, chaque tour a la sienne et la boucle affiche 0, 1, 2.

3. Qu’est-ce qu’une closure (fermeture) ? Une fonction qui garde l’accès aux variables de la portée où elle a été créée, même après la fin de cette portée. Exemple : function compteur() { let n = 0; return () => ++n; } (MDN, closures).

4. Dans quel ordre s’affichent console.log('A'), un setTimeout à 0 ms, une promesse résolue puis console.log('B') ? A, B, puis la promesse, puis le setTimeout. Le code synchrone passe d’abord ; les rappels de promesses (microtâches) passent avant les tâches comme setTimeout (MDN, modèle d’exécution).

HTTP et API REST

5. GET, POST, PUT, DELETE : lesquelles sont idempotentes ? GET, PUT et DELETE : plusieurs requêtes identiques ont le même effet voulu qu’une seule. La réponse peut différer : un second DELETE peut renvoyer 404 sans que la méthode cesse d’être idempotente. POST ne l’est pas. GET, HEAD et OPTIONS sont en plus des méthodes sûres, en lecture seule (RFC 9110, section 9.2).

6. 401 ou 403 ? 401 signifie que la requête n’a pas d’identifiants valides ; le serveur doit alors indiquer comment s’authentifier. 403 signifie que le serveur a compris la requête mais refuse de l’exécuter. Selon la RFC 9110, le client ne devrait pas la répéter automatiquement avec les mêmes identifiants, peut réessayer avec d’autres, et le refus peut n’avoir aucun lien avec les identifiants (RFC 9110, section 15.5.4).

7. Quel code renvoyer après une création et après une suppression ? 201 Created après une création, avec l’adresse de la ressource dans l’en-tête Location. Après un DELETE réussi, la RFC 9110 prévoit 204 sans corps, 200 avec un corps décrivant le résultat, ou 202 si la suppression n’est pas encore faite (RFC 9110, section 9.3.5). Notre tutoriel pour créer une API REST avec Node.js et Express applique ces codes.

8. À quoi sert CORS ? La politique de même origine du navigateur empêche une page de lire les réponses d’une autre origine. CORS permet au serveur d’assouplir cette règle par des en-têtes HTTP, en désignant les origines autorisées. Ce n’est pas un contrôle d’accès à votre API : curl ou un autre serveur ignorent ces en-têtes (MDN, CORS).

SQL

9. INNER JOIN ou LEFT JOIN ? INNER JOIN ne garde que les lignes qui ont une correspondance des deux côtés. LEFT JOIN garde toutes les lignes de la table de gauche, avec des NULL quand il n’y a pas de correspondance. Pour trouver les clients sans commande : LEFT JOIN commandes ... WHERE commandes.id IS NULL (PostgreSQL, jointures).

10. WHERE ou HAVING ? WHERE filtre les lignes avant le regroupement ; HAVING filtre les groupes après le calcul des agrégats. GROUP BY client_id HAVING COUNT(*) >= 2 liste les clients qui ont au moins deux commandes (PostgreSQL, agrégats).

11. Pourquoi ne pas indexer toutes les colonnes ? Un index accélère la recherche, mais il occupe de l’espace et chaque insertion ou mise à jour doit aussi le maintenir ; on indexe donc les colonnes souvent filtrées, triées ou jointes (PostgreSQL, index).

Git

12. Merge ou rebase ? Merge conserve l’historique et ajoute un commit de fusion, sauf en cas d’avance rapide ; rebase rejoue vos commits sur la pointe d’une autre branche et donne un historique linéaire, en réécrivant ces commits. Le livre Pro Git recommande de ne jamais rebaser des commits déjà poussés sur un dépôt public (Pro Git, rebaser).

13. Comment annuler un commit déjà poussé ? Avec git revert, qui crée un nouveau commit inverse sans réécrire l’historique partagé (git revert). git reset déplace la branche et convient surtout aux commits encore locaux (git reset).

Docker et ligne de commande

14. Image ou conteneur ? Une image est un modèle en lecture seule, construit en couches ; un conteneur est une instance exécutable de cette image, isolée du reste de la machine, avec sa propre couche inscriptible (Docker, qu’est-ce qu’une image).

15. Comment garder les données d’une base dans Docker ? Avec un volume : les données écrites dans le système de fichiers du conteneur disparaissent avec lui, alors qu’un volume est géré par Docker et survit à la suppression du conteneur (Docker, volumes). Notre tutoriel Docker pour débutants le montre pas à pas. Pour les questions de terminal, révisez nos commandes Linux de base.

Sécurité

16. Comment éviter une injection SQL ? Avec des requêtes paramétrées (requêtes préparées), qui séparent le code SQL des données, plutôt qu’en concaténant des chaînes. C’est la première défense recommandée par l’OWASP (OWASP, injection SQL). L’injection figure toujours dans le Top 10 2025 de l’OWASP, en cinquième position.

17. Comment stocker un mot de passe ? Jamais en clair ni chiffré de façon réversible : on le hache avec un algorithme lent et salé. L’OWASP recommande Argon2id, puis scrypt si Argon2id est indisponible, bcrypt pour les systèmes existants et PBKDF2 quand la conformité FIPS-140 est exigée (OWASP, stockage des mots de passe).

Algorithmique

18. Pourquoi un Set est-il plus rapide qu’un tableau pour tester l’appartenance ? tableau.includes(x) parcourt les éléments un par un : O(n). La spécification impose à un Set un temps d’accès moyen sous-linéaire ; en pratique, les moteurs utilisent une table de hachage, avec une recherche en O(1) en moyenne, au prix de mémoire en plus (MDN, Set).


Penser à voix haute en live coding : un exemple corrigé

En live coding, l’intervieweur ne peut pas noter un raisonnement qu’il n’entend pas. Une méthode en six temps structure ce que vous dites :

  1. Reformuler le problème et poser les questions de cadrage.
  2. Donner des exemples, dont des cas limites : tableau vide, doublons, valeur absente.
  3. Proposer une solution simple et annoncer sa complexité.
  4. L’améliorer en expliquant le compromis.
  5. Coder en commentant les choix.
  6. Tester à la main sur les exemples, puis conclure sur la complexité.

L’énoncé. Un tableau de nombres et une cible sont donnés ; renvoyer les indices de deux éléments situés à des positions différentes dont la somme vaut la cible, ou null s’il n’y en a pas.

Ce que vous dites d’abord. « Je cherche deux positions différentes. Le tableau peut-il être vide ? Une seule paire suffit ? » Puis vos exemples : [2, 7, 11, 15] avec la cible 9 donne [0, 1] ; [3, 3] avec 6 donne [0, 1] ; [1, 2, 3] avec 7 donne null.

La solution simple. « Je peux tester toutes les paires avec deux boucles. C’est correct, mais en O(n²) ; sur un grand tableau, ce sera lent. »

L’amélioration. « En parcourant le tableau une fois, je peux mémoriser chaque valeur vue et son indice dans une Map. Pour chaque nombre, je cherche si son complément, cible moins nombre, a déjà été vu. »

function deuxSommes(nombres, cible) {
  const vus = new Map(); // valeur -> indice
  for (let i = 0; i < nombres.length; i++) {
    const complement = cible - nombres[i];
    if (vus.has(complement)) return [vus.get(complement), i];
    vus.set(nombres[i], i);
  }
  return null;
}

deuxSommes([2, 7, 11, 15], 9); // [0, 1]
deuxSommes([3, 2, 4], 6);      // [1, 2]
deuxSommes([1, 2, 3], 7);      // null

Le détail à dire à voix haute. On teste le complément avant d’ajouter le nombre courant. Sinon, [3, 2, 4] avec la cible 6 renverrait [0, 0], en utilisant deux fois le 3.

La conclusion. « Temps O(n) en moyenne, un seul parcours ; mémoire O(n) pour la Map. » Nous avons exécuté ce code et la version à deux boucles avec Node.js 22 sur six cas, dont un tableau vide, une paire en double et des nombres négatifs : les deux versions renvoient une paire valide, ou null, sur les six cas.

Si vous bloquez, dites-le et décrivez où : « Je vois la solution en O(n²), je cherche à éviter la seconde boucle. » Un intervieweur peut alors vous orienter, ce qu’il ne peut pas faire face au silence.


Le test à la maison : temps, consignes et droits sur votre code

Ce test technique à la maison, un mini-projet selon OpenClassrooms, mesure ce que vous livrez seul : un code propre, testé et documenté compte plus qu’une fonctionnalité de trop.

Le temps. Aucune source lue ne fixe de durée maximale : demandez le temps attendu et respectez-le. Dans le README, indiquez le temps passé, vos choix et ce que vous feriez avec plus de temps.

Vos droits de candidat. Le Code du travail encadre ces tests. Selon l’article L1221-6, les informations demandées au candidat « doivent présenter un lien direct et nécessaire avec l’emploi proposé ou avec l’évaluation des aptitudes professionnelles ». L’article L1221-8 prévoit que le candidat est « expressément informé, préalablement à leur mise en oeuvre, des méthodes et techniques d’aide au recrutement », que les résultats sont confidentiels et que ces méthodes doivent être pertinentes (Code du travail numérique, L1221-8, consulté le 1er novembre 2026 ; L1221-6).

Qui possède le code ? Le Code de la propriété intellectuelle protège les logiciels comme œuvres de l’esprit, et l’auteur a des droits sur son œuvre « du seul fait de sa création » (article L112-2 et article L111-1, consultés le 1er novembre 2026). Encore faut-il que le code soit original : la Cour de cassation exige un « apport intellectuel propre » et un « effort personnalisé » (Journal du Net, sur l’arrêt du 17 octobre 2012), ce qui est discutable pour un exercice court.

L’article L113-9 attribue à l’employeur les droits sur les logiciels créés par des employés dans l’exercice de leurs fonctions (article L113-9). Un candidat n’est pas encore un employé : à notre lecture, le code d’un test reste à son auteur, sauf contrat contraire. Ce n’est pas un avis juridique. Lisez ce que l’on vous fait accepter, demandez par écrit si votre code sera réutilisé, et vérifiez que l’énoncé n’est pas confidentiel avant de le publier sur GitHub.


L’IA pendant les tests : ce que disent les règles publiées

Certaines entreprises interdisent l’IA pendant un test technique, d’autres l’exigent ; HackerRank, éditeur de tests, note que les employeurs décident encore quand l’autoriser (HackerRank, Developer Skills Report 2025, consulté le 1er novembre 2026).

Entreprise Test à la maison Entretien en direct Source
Anthropic Sans Claude, sauf indication contraire « Pas d’assistance par IA, sauf indication contraire » (notre traduction) Conseils aux candidats
Canva (postes back-end, front-end et apprentissage automatique) Non précisé dans le billet Usage des outils d’IA attendu dans l’entretien de code assisté par IA Blog d’ingénierie de Canva, 11 juin 2025

Chez Canva, les problèmes posés « ne peuvent pas être résolus avec un seul prompt » (notre traduction), et l’évaluation porte sur le découpage d’un besoin ambigu et la correction du code généré.

Graphique en barres : avis des développeurs sur les tests techniques selon HackerRank 2025, de 96 % qui veulent que résoudre compte plus que mémoriser à 56 % qui jugent l'algorithmique sans rapport avec leur poste

Dans le même rapport, une enquête mondiale auprès de 13 732 répondants, 76 % des développeurs pensent que l’IA facilite la triche.

La règle pratique : si la consigne ne dit rien, demandez au recruteur avant de commencer. Si l’IA est autorisée, montrez que vous relisez et testez ce qu’elle produit. Voir aussi notre article sur l’usage de l’IA pour coder.


Les questions à poser au recruteur

Préparez au moins une question précise pour chaque interlocuteur :

  • Au recruteur : quelles sont les prochaines étapes, et dans quels délais ? Quelle est la fourchette de salaire du poste ? Le télétravail est-il possible, et à quel rythme ?
  • Au manager technique : comment se passe l’intégration d’un nouveau développeur le premier mois ? Comment le code est-il relu avant d’être fusionné ? Comment déployez-vous en production ?
  • Aux futurs collègues : quelle est la part de tests automatisés ? Existe-t-il des astreintes ? Pour un poste junior, qui sera mon référent ?

Après l’entretien

Juste après l’entretien, notez les questions techniques posées et celles où vous avez hésité : c’est votre programme de révision.

Envoyez dans la journée un message court au recruteur : un remerciement et un point précis de l’échange. Puis attendez : le processus complet est souvent long, et le rapport de HackerRank note que beaucoup de candidats attendent des semaines ou ne reçoivent aucune réponse.

Sans nouvelles à la date annoncée, relancez poliment le recruteur. En cas de refus, demandez un retour sur le test technique.


Trois erreurs à éviter

En plus du silence en live coding et du bluff, trois erreurs se corrigent avant l’entretien :

  • Sur-concevoir. Une architecture à microservices pour un test de deux heures inquiète plus qu’elle ne rassure.
  • Ne pas connaître son propre CV. Chaque technologie citée peut devenir une question.
  • Critiquer un ancien employeur. L’entretien final évalue aussi votre manière de travailler en équipe.

Ce que nous n’avons pas pu vérifier

Plusieurs points restent incertains :

  • La fréquence du live coding et du test à la maison en France : aucune source chiffrée lue ne les distingue.
  • Les politiques sur l’IA des employeurs français. Nous n’en avons trouvé aucune publiée ; les exemples cités sont américain et australien.
  • La pratique actuelle de Canva. Le billet date de juin 2025 ; le format a pu évoluer depuis.

Questions fréquentes

Combien de temps dure un entretien technique développeur ?

La discussion technique dure généralement de 30 à 45 minutes et peut aller jusqu’à 1 h 30, selon le cours d’OpenClassrooms. Le processus complet prend plusieurs semaines : 12 en moyenne pour un recrutement de cadre en 2025, selon l’Apec.

Comment se préparer à un entretien technique de développeur junior ?

Révisez les fondamentaux (JavaScript, HTTP, SQL, Git), entraînez-vous à voix haute sur des exercices courts et relisez vos projets.

Peut-on utiliser ChatGPT pendant un test technique ?

Seulement si l’entreprise l’autorise. Les règles varient : Anthropic interdit l’IA sauf indication contraire, Canva l’attend dans un de ses entretiens. Sans consigne écrite, demandez avant de commencer.

Que faire si je ne connais pas la réponse à une question technique ?

Dites-le, puis expliquez comment vous trouveriez la réponse. OpenClassrooms recommande d’admettre ce que l’on ne sait pas.


À propos de l’auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d’IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Synthèse fondée exclusivement sur des sources publiques : baromètre 2026 de l’Apec, rapport 2025 de HackerRank, cours d’OpenClassrooms, politiques publiées par Anthropic et Canva, Code du travail, Code de la propriété intellectuelle, documentation de MDN, PostgreSQL, Git, Docker, de l’IETF et de l’OWASP. Les chiffres d’éditeurs sont signalés comme tels et les citations en anglais sont traduites par nos soins. Seul le code de l’exercice de live coding a été exécuté. Aucun test n’a été mené auprès de recruteurs, aucun lien n’est affilié et aucune relation commerciale ne lie l’auteur aux entreprises mentionnées.

Limites. L’Apec porte sur l’ensemble des recrutements de cadres et HackerRank sur un échantillon mondial : aucune des deux enquêtes ne mesure spécifiquement les développeurs en France. Notre lecture du Code de la propriété intellectuelle sur le code d’un test n’est pas un avis juridique ; nous n’avons trouvé aucune décision de justice sur ce cas précis.

Une erreur ou une règle périmée ? Écrivez à [email protected] : l’article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 1er novembre 2026.

Image : Vitaly Gariev (Unsplash License).

Publications similaires