Entretien client en ESN : présenter votre mission et prouver vos compétences

Vous avez un entretien avec le client d’une ESN et votre dossier de compétences semble correspondre à la mission. Pourtant, une liste « Java, Spring, PostgreSQL, Kubernetes » ne répond pas à la question décisive : que pourrez-vous prendre en charge, avec quelles preuves et quel accompagnement ? Préparez cette correspondance avant de répéter votre parcours.

Notre angle : relier un besoin de mission à votre contribution personnelle, à une preuve examinable et à une limite annoncée. Cette préparation vous donne une trame pour présenter un projet pertinent, répondre aux relances et repérer les conditions encore inconnues. Pour commencer, Explain Your Engineering Ownership permet de travailler la différence entre les réalisations de l’équipe et vos propres décisions.

Ce que les sources permettent de dire sur l’entretien client

Source officielle métier : l’Onisep décrit le conseil informatique autour de l’analyse des besoins et de solutions adaptées à l’organisation du client. Cette description éclaire le rôle ; elle ne fixe ni les étapes ni la durée de votre entretien.

Conseils d’une ESN : dans un article publié le 17 septembre 2025, Kent recommande de préparer des expériences pertinentes, de préciser son rôle et de poser des questions sur la mission. Il s’agit des conseils de cette entreprise, pas d’un protocole commun à toutes les ESN.

Deux témoignages candidats de 2026, non vérifiés indépendamment : le 16 septembre, un auteur de r/developpeurs rapporte une demande de masquer le caractère en alternance d’une expérience avant un échange client. Le 6 octobre, un autre auteur décrit un accord client annoncé par une ESN, puis une proposition d’une autre ESN pour la même mission. Ces récits indépendants ne mesurent aucune fréquence et n’établissent pas une pratique générale.

Notre déduction de préparation : vérifiez la cohérence du dossier envoyé et distinguez la validation technique de la mission des conditions encore à confirmer avec l’ESN. Les situations rapportées justifient des questions, pas une prédiction sur votre propre processus.

Obtenir un brief qui permet de choisir ses preuves

Avant l’échange, demandez au contact ESN la version du dossier transmise au client et le besoin auquel votre profil est censé répondre. Relisez les dates, le statut des expériences et les responsabilités. Si le dossier vous attribue la responsabilité d’un service auquel vous avez seulement contribué, faites corriger ce point avant l’échange client.

Demandez ensuite quatre informations : le travail attendu au démarrage, les interlocuteurs présents, les contraintes du système et le niveau d’autonomie recherché. « Backend Java » peut désigner une API à construire, des incidents à diagnostiquer ou un service existant à reprendre. Ces situations appellent des preuves différentes.

Voici un brief fictif, construit pour cet article : une équipe utilise Java/Spring et PostgreSQL. Elle souhaite fiabiliser un import CSV de commandes, expliquer les rejets aux utilisateurs et faciliter l’investigation. Le service tourne sur Kubernetes, mais la répartition du support entre développeurs et équipe plateforme reste inconnue.

Ne déduisez pas de cette dernière ligne que vous devrez administrer le cluster. Demandez si le besoin porte sur les logs applicatifs, les déploiements, les ressources des pods ou l’exploitation du cluster. La réponse détermine la compétence à démontrer et celle qu’il faut signaler comme un écart.

Construire une matrice mission, preuve et limite

Préparez cette matrice avec vos expériences réelles. Le tableau ci-dessous appartient au cas fictif ; ses éléments ne deviennent pas votre parcours parce que vous les avez lus.

Classez chaque ligne : déjà réalisé, compétence transférable, écart à combler. « Je sais valider des données dans un autre langage » relève du transfert ; « j’ai maintenu ce service Spring » exige une expérience correspondante. Le client peut alors distinguer une expérience démontrée d’une compétence encore à vérifier.

Choisissez une preuve principale et une preuve de secours par besoin essentiel. Un extrait réduit de code peut montrer la règle ; un test peut montrer son comportement aux limites. Une capture indiquant seulement un taux d’erreur ne dit pas quelle alerte vous avez modifiée ni pourquoi.

Pour chaque résultat, notez comment vous le savez. Un comptage local, une observation en recette et une mesure en production sont trois niveaux différents. Si vous n’avez pas conservé la mesure, décrivez le changement observé sans inventer de pourcentage. Utilisez des données synthétiques et des supports dont le partage est autorisé ; un extrait confidentiel n’est pas nécessaire pour expliquer votre raisonnement.

Montrer un résultat vérifiable avec le cas CSV

Notre démonstration originale utilise Python pour isoler une règle métier. Elle n’est ni un projet client ni une preuve d’expérience Java. Le fichier possède exactement quatre colonnes, dans cet ordre :

order_id,sku,qty,requested_date
O-101,BOOK,2,2026-10-15
O-102,PEN,0,2026-10-15
O-103,BOOK,1,2026-02-30

Le contrat local accepte les références BOOK et PEN, une quantité entière strictement positive et une date calendaire au format exact YYYY-MM-DD. Le classificateur conserve la première raison de rejet par enregistrement. Il sépare les lignes valides des rejets ; il n’écrit rien en base.

Le résultat exécuté est précis : O-101 est accepté pour la validation ; O-102 est rejeté pour qty ; O-103 est rejeté pour date. Dans ce fichier simple, les rejets portent les numéros 3 et 4, en comptant l’en-tête. Ce compteur d’enregistrements ne garantit pas le numéro physique d’une ligne dans un CSV contenant des champs multilignes.

Documentation officielle : csv.DictReader associe les champs aux colonnes et permet de détecter des champs supplémentaires ou manquants. date.fromisoformat accepte plusieurs formes ISO ; notre exercice exige donc d’abord la forme YYYY-MM-DD, puis vérifie la validité calendaire. Ce format strict est notre choix métier, pas une restriction attribuée à Python.

La fixture originale et son résultat enregistré documentent 13 scénarios nommés exécutés sur CPython 3.12.14 : cas de démonstration, quantité négative, décimale ou vide, référence inconnue, identifiant vide, colonne manquante ou supplémentaire, date compacte, date de semaine, en-tête seul, jour bissextile valide et mauvais en-tête.

Cette preuve laisse plusieurs sujets ouverts : doublons de commandes, transaction de persistance, concurrence, performance, sécurité des exports et déploiement. Lors d’un entretien, ces limites fournissent de bonnes relances. Elles ne doivent pas devenir des fonctions prétendument terminées.

Présenter ce projet avec une trame de deux minutes

Deux minutes sont ici un objectif de répétition, pas une durée officielle ni une mesure de lecture. Adaptez la trame à votre projet réel et au temps proposé par l’interlocuteur. Pour la démonstration fictive, vous pourriez dire :

« J’ai construit un exercice local pour rendre les rejets d’un import explicables. Le risque étudié est d’accepter une commande dont la quantité ou la date ne respecte pas le contrat. J’ai séparé la classification de la persistance : le programme produit des lignes validées et des rejets avec une raison. »

« Sur ces trois commandes, la première passe, la deuxième échoue sur la quantité zéro et la troisième sur une date impossible. Les 13 scénarios locaux couvrent aussi des colonnes incorrectes et plusieurs formats de date. Je peux montrer le cas qui échoue et la règle correspondante. »

« Cette démonstration ne traite pas la transaction PostgreSQL ni les doublons. Pour votre service Spring, je commencerais par confirmer l’unité de traitement et le comportement attendu après une reprise. J’aimerais savoir si un fichier partiellement valide doit être rejeté en bloc ou traité ligne par ligne. »

La dernière question rejoint le besoin client. Elle évite de terminer par une promesse vague de transposer rapidement le code. Pour une expérience professionnelle, remplacez « exercice local » par le contexte exact, puis nommez vos décisions et les validations effectivement réalisées.

Préparez également une version courte : besoin, contribution, preuve, limite. Si le client vous interrompt sur PostgreSQL, suivez cette relance ; ne récitez pas le reste de votre présentation. Le support permet au client de choisir la décision technique qu’il souhaite approfondir.

Répondre aux relances sans élargir artificiellement son expérience

« Vous avez fait cela en Python ; pourquoi êtes-vous pertinent pour Spring ? » Séparez le raisonnement transférable de la compétence de framework. Vous pouvez défendre le contrat de validation et les cas limites. Pour Spring, appuyez-vous sur un travail réel distinct ou annoncez que cette partie reste à démontrer.

« Pourquoi ne pas insérer chaque ligne immédiatement ? » Expliquez la décision de l’exercice : isoler les erreurs de données avant de choisir une politique de persistance. Puis demandez le contrat réel : atomicité du fichier, reprise après échec et identification des doublons. Aucune réponse unique ne découle du CSV seul.

« Pouvez-vous assurer le support Kubernetes ? » Précisez ce que vous avez déjà fait : lire des logs applicatifs, analyser un redémarrage, modifier un déploiement ou administrer un cluster sont des responsabilités différentes. Si vous n’avez pas réalisé une tâche, dites-le et demandez le périmètre d’accompagnement.

« Quel gain avez-vous obtenu ? » Pour notre exemple, la seule preuve est le comportement local vérifié. Ne transformez pas 13 scénarios réussis en baisse des incidents ou en amélioration du temps de traitement. Pour votre propre projet, donnez une mesure uniquement si vous pouvez en expliquer la collecte et les limites.

Poser des questions qui changent la décision de mission

Concentrez-vous sur les inconnues susceptibles de modifier votre préparation ou votre capacité à livrer. Vous n’avez pas besoin de poser toutes les questions si le client a déjà répondu.

Si une réponse révèle un écart important, reformulez-le : « Je peux prendre en charge la validation applicative ; la responsabilité d’exploitation du cluster reste à préciser. » Une formulation précise permet de discuter de l’accompagnement nécessaire.

Après l’échange, envoyez à votre contact ESN une synthèse factuelle : besoin compris, preuves discutées, points ouverts et prochaine étape annoncée. Un « GO client » rapporté ne renseigne pas à lui seul sur tous les détails de démarrage. Faites confirmer les éléments encore ouverts par les interlocuteurs concernés, sans transformer cet article en conseil contractuel.

Cinq questions pour s’entraîner avant l’échange

Ces questions PracHub proviennent de contextes variés. Nous les sélectionnons pour les compétences exercées ; elles ne prédisent pas les questions de votre client ESN. Gardez leurs contraintes d’origine lorsque vous les travaillez.

Commencez par Explain Technical Tradeoffs in a Project You Led avec votre matrice mission/preuve. Vérifiez que chaque responsabilité, résultat et limite de votre réponse correspond à une expérience que vous pouvez expliquer.

Sources and Further Reading

• Onisep — Consultant / consultante informatique — source officielle sur le métier, sans protocole d’entretien universel.
• Kent — Réussir son entretien client en ESN : 8 conseils clés pour convaincre — conseils de cette ESN, publiés le 17 septembre 2025.
• Témoignage du 16 septembre 2026 sur la présentation d’une expérience — récit auto-déclaré, non vérifié indépendamment.
• Témoignage du 6 octobre 2026 sur deux ESN pour un même client — récit auto-déclaré, sans conclusion générale sur les offres.
• Python 3.12 — csv.DictReader — comportement du lecteur CSV.
• Python 3.12 — date.fromisoformat — formes ISO acceptées et validation calendaire.