Back-end developer (développeur back-end)

Le développeur back-end, ou back-end developer, conçoit et maintient la partie serveur d’une application web. Il transforme les besoins du produit en traitements, organise les échanges avec les données et fournit les réponses dont les interfaces ou d’autres services ont besoin. Son travail est moins visible que l’écran utilisé par le client, mais il conditionne le fonctionnement des règles métier et la fiabilité des données.

Son périmètre commence par la compréhension des besoins et des spécifications. Il développe ensuite les composants serveur, adapte les accès aux bases de données et vérifie que les requêtes reçues produisent les réponses attendues. Une API peut servir de contrat d’échange avec une interface ou un autre service. Selon le produit, le développeur intervient aussi sur la validation des entrées, les autorisations, les tests, la correction des bugs et la documentation nécessaire à la maintenance. Ces tâches ne signifient pas qu’une seule personne porte toute la sécurité ou toute l’exploitation de l’application.

La taille de l’organisation et la complexité du projet changent la répartition du travail. Dans une petite équipe, un développeur peut toucher à plusieurs parties du produit. Dans une organisation plus grande, il peut se concentrer sur un module serveur. Le poste doit donc nommer les traitements à construire, les données concernées et les décisions techniques confiées, plutôt que supposer qu’un intitulé fixe le même périmètre partout.

Développeur back-end, développeur front-end et développeur full-stack : qui fait quoi ?

• Le développeur back-end prend en charge les traitements serveur, les accès aux données et les réponses transmises aux interfaces ou aux services.
• Le développeur front-end travaille sur la partie visible et interactive de l’application. Il échange avec le back-end sur les données et comportements attendus.
• Le développeur full-stack intervient sur les deux côtés. Cette appellation ne dispense pas de préciser la part réelle d’interface et de serveur dans le poste.

Le rôle décrit ici reste centré sur le code serveur. Le développement général des interfaces, les pipelines analytiques et l’administration de l’infrastructure ne deviennent des responsabilités du poste que si l’organisation les ajoute explicitement.

Le recrutement répond d’abord à une question de responsabilité : qui peut faire évoluer les traitements et les données de l’application sans rendre les changements difficiles à tester ou à maintenir ? Un besoin formulé comme « développer le back-end » reste trop large. Les règles métier à traduire en code, les réponses attendues par les interfaces et les données à créer ou modifier donnent un périmètre plus utile aux candidats comme aux évaluateurs.

Une erreur de cadrage consiste à demander simultanément une forte spécialisation serveur et la prise en charge générale des interfaces, sans indiquer la priorité. Un profil full-stack peut convenir si ces deux ensembles de tâches font réellement partie du poste. Si l’équipe possède déjà des développeurs d’interface et doit surtout faire évoluer les composants serveur, le besoin est différent. La répartition doit aussi préciser qui décide du modèle de données et qui accompagne les changements touchant l’exploitation.

La sécurité entre dans les choix quotidiens du code serveur. Les entrées reçues doivent être validées, et les accès aux données doivent respecter les droits prévus par l’application. La performance demande, elle aussi, une attention proportionnée aux traitements et à la charge du produit. Ces sujets peuvent être évalués à partir d’un travail concret, sans attendre que le candidat garantisse à lui seul tous les résultats de sécurité ou de disponibilité.

Exemple fictif : une équipe ajoute un nouvel espace client. L’interface est déjà prise en charge, mais les données doivent être enregistrées et restituées selon les droits de chaque utilisateur. Le recrutement peut alors cibler la conception des traitements serveur, la validation des demandes, les tests et la documentation de ces changements. Ce scénario sert à préciser le poste ; il ne décrit pas une mission observée.

Enfin, le poste ne se limite pas à la première livraison. Les bugs, les changements de besoins et l’évolution des données demandent des corrections documentées. Décrire cette part de maintenance aide à choisir un candidat capable d’expliquer ses choix et de reprendre un composant existant, pas seulement de produire un nouveau code.

• Analyser les besoins et spécifications qui concernent les traitements serveur.
• Développer les règles métier de l’application dans des composants serveur.
• Concevoir ou adapter le modèle de données nécessaire aux fonctionnalités confiées.
• Créer et maintenir les accès aux données en tenant compte des droits et de la confidentialité.
• Produire les réponses ou API attendues par les interfaces et les services consommateurs.
• Valider les données reçues avant leur traitement.
• Tester les composants serveur et corriger les dysfonctionnements constatés.
• Documenter les changements pour faciliter la maintenance de l’application.

Plusieurs parcours peuvent préparer au développement back-end. L’Apec mentionne des études informatiques de différents niveaux, tandis qu’un titre professionnel peut être obtenu par un parcours de formation ou par capitalisation de compétences. Ces voies renseignent sur les acquis possibles ; elles ne constituent pas, à elles seules, une condition universelle d’accès au poste. La décision de recrutement gagne à partir des tâches confiées.

Pour examiner ces acquis, demandez au candidat de montrer un projet serveur dont il peut expliquer le fonctionnement. Un traitement métier, un accès aux données ou une réponse d’API donne matière à discussion. Le candidat doit pouvoir décrire le besoin initial, les choix de conception, les entrées contrôlées et les tests effectués. Un dossier de projet ou une documentation peut aider à distinguer ce qu’il a réellement réalisé du travail collectif.

La formation utile couvre également le cycle de vie du code. Savoir écrire un composant est une première capacité ; le modifier après un bug, expliquer la correction et vérifier son effet en est une autre. Les connaissances en bases de données et en sécurité doivent être appréciées dans le contexte des données traitées. Un exercice lié à l’application à maintenir sera plus parlant qu’une liste de technologies sans usage défini.

L’expérience attendue dépend de la complexité du projet et du soutien disponible dans l’équipe. Décrivez les responsabilités déjà exercées que vous recherchez : réaliser une tâche encadrée, reprendre un module existant ou choisir une solution pour un traitement plus complexe. Le nombre d’années, à lui seul, ne précise ni l’autonomie ni le travail accompli. Aucun seuil commun n’est retenu pour cette fiche.

Pour évaluer ce profil, adaptez les étapes suivantes aux traitements serveur à confier, aux données manipulées et à l’autonomie attendue.

1. Fixer les critères du poste

Établissez une grille courte avant les entretiens. Séparez la programmation des règles métier, la conception des accès aux données, les échanges par API, les tests et la sécurité des entrées. Pour chaque critère, définissez ce que la personne devra faire dans votre application. Une équipe qui possède déjà un cadre technique peut attendre une exécution soignée. Un poste de conception demande aussi de justifier des arbitrages.

Associez chaque critère à un livrable observable : un composant expliqué, un schéma de données, des tests ou une correction documentée. Cela évite de confondre la connaissance d’un nom de framework avec la capacité à résoudre le problème du poste.

2. Examiner une réalisation passée

Demandez au candidat de présenter un traitement serveur qu’il a développé ou modifié. Faites préciser le besoin, sa contribution personnelle, le chemin d’une requête jusqu’aux données et la réponse produite. Interrogez-le sur un bug corrigé et sur les tests qui ont permis de vérifier le résultat.

Un signal favorable est une explication qui relie les choix techniques aux contraintes du produit. Une alerte est l’impossibilité de distinguer sa contribution de celle de l’équipe. Un projet et son dossier peuvent servir de support à cet échange ; leur présence ne prouve pas à elle seule la maîtrise.

3. Utiliser un cas proche du travail prévu

Présentez un cas limité à un traitement, une API ou un accès aux données. Demandez au candidat d’expliciter les informations manquantes avant de coder ou de dessiner une solution. Observez comment il définit les entrées, les réponses, les droits d’accès et les tests utiles.

Exemple fictif : une requête doit restituer des données à une interface, mais certains utilisateurs ne doivent voir qu’une partie des résultats. Invitez le candidat à expliquer la validation des entrées, le contrôle d’accès et la vérification du comportement. Plusieurs solutions peuvent être recevables si leurs limites sont comprises.

4. Apprécier la collaboration et l’autonomie

Demandez comment il clarifierait avec une personne produit une règle métier ambiguë, puis avec le front-end le format d’une réponse. Vérifiez qu’il sait signaler une hypothèse et documenter une correction. Pour un poste autonome, examinez aussi la manière dont il déciderait quand demander une revue ou une expertise complémentaire.

L’alerte n’est pas un vocabulaire différent de celui de l’équipe. Elle apparaît lorsque le candidat ne peut pas expliquer qui doit trancher une règle ou ce que son code change pour les autres composants.

5. Recouper les éléments

Avec l’accord préalable du candidat, dans les échanges de références professionnels, demandez des exemples précis de maintenance, de coopération et de responsabilités réellement exercées. Comparez ces réponses au projet présenté et au cas pratique, sans traiter une seule réponse comme une preuve définitive.

Si personne dans l’entreprise ne peut apprécier la conception serveur, faites participer un professionnel compétent à l’entretien technique. Transmettez-lui les critères du poste et demandez un avis argumenté sur les livrables et les choix, puis confrontez cet avis aux besoins de l’équipe.