Questions d'entretien Développeur backend

Je commence par les consommateurs de l'API avant de penser à l'implémentation. Les premières questions que je pose sont : qui appellera cette API, de quelles données a-t-il réellement besoin, et quelles opérations ont du sens d'un point de vue ressource ? À partir de là, je conçois autour des ressources et des verbes HTTP standard, en gardant les URLs basées sur des noms et en utilisant les codes de statut de manière cohérente plutôt que d'enfouir les erreurs dans des réponses 200. Je documente au fur et à mesure avec OpenAPI car un schéma qui existe dès le premier jour évite que l'API dérive de son contrat. Je versionne aussi dès le début : ajouter /v1/ au chemin de base ne coûte rien au départ et évite un travail de migration douloureux plus tard. Avant de finaliser toute API, je la passe en revue avec les équipes qui vont l'utiliser, car le meilleur signal qu'une conception est juste, c'est que le consommateur peut écrire son code d'intégration sans avoir besoin de me poser des questions.

La sécurité est une préoccupation de conception, pas une étape de révision à la fin. Mon point de départ est l'OWASP Top 10 : injection SQL, authentification défaillante, exposition excessive des données, etc. Ce ne sont pas des vecteurs d'attaque exotiques ; ils sont à l'origine de la plupart des violations réelles. Concrètement, cela signifie des requêtes paramétrées partout, aucun secret dans le code ni dans les logs, une validation JWT avec une expiration correcte, et une validation des entrées à la frontière de l'API plutôt que de faire confiance au client. Pour les données sensibles, j'applique le principe du moindre privilège au niveau de la base de données : les services n'ont accès qu'aux tables dont ils ont besoin. J'intègre aussi une limitation de débit sur les endpoints publics pour prévenir les abus. J'encourage les membres de l'équipe à signaler les problèmes tôt, car une vulnérabilité détectée en code review coûte bien moins cher que celle découverte en production.

J'aborde les problèmes de performance comme tout problème de débogage : mesurer avant de changer quoi que ce soit. La pire chose à faire est d'optimiser quelque chose qui n'est pas le vrai goulot d'étranglement. Ma première étape est toujours d'identifier le chemin lent grâce aux outils de profiling ou aux données APM. Dans la plupart des cas, la réponse est la base de données : les index manquants, les patterns N+1 ou le chargement de plus de données que nécessaire sont responsables de la majorité des ralentissements backend que j'ai rencontrés. Une fois le goulot identifié, je cherche d'abord le correctif le moins coûteux. Ajouter un index prend quelques minutes et peut améliorer une requête d'un ordre de grandeur. Si le problème est structurel, je regarde la mise en cache avec Redis pour les données lues fréquemment mais peu modifiées, et le traitement asynchrone pour les opérations qui n'ont pas besoin d'être synchrones. Je mesure toujours avant et après un changement et documente le résultat pour que l'équipe comprenne ce que nous avons gagné.

L'IA a changé mon flux de travail quotidien de manière concrète. Pour le code boilerplate : créer un nouveau service, scaffolder une suite de tests, écrire des migrations, l'IA me donne un premier brouillon solide en quelques minutes que je révise et ajuste ensuite. La valeur n'est pas seulement la vitesse ; elle réduit la charge cognitive liée au passage entre la logique que je conçois et la syntaxe et le scaffolding nécessaires pour l'exprimer. Pour déboguer des bases de code inconnues ou tracer un message d'erreur que je n'ai pas vu auparavant, l'IA identifie souvent la cause probable plus rapidement qu'une recherche. Là où je fais plus attention, c'est avec le code sensible à la sécurité : je ne colle jamais de secrets ou de données personnelles dans un modèle public, et je révise toujours soigneusement tout code d'authentification ou d'autorisation généré par l'IA, car les erreurs subtiles dans ces zones ont les plus grandes conséquences. J'utilise aussi l'IA pour générer des cas de test, en lui demandant de considérer les cas limites que j'aurais pu manquer, ce qui a permis de détecter de vrais bugs avant qu'ils n'atteignent la production.

Notre service de traitement des paiements a commencé à générer des erreurs 500 intermittentes un vendredi après-midi, affectant environ 3 % des transactions. J'ai rejoint l'appel d'incident, consulté les logs, et en dix minutes j'ai identifié que les erreurs se regroupaient autour d'un réplica de base de données qui avait pris du retard dans la réplication. La cause principale était une requête longue introduite dans un déploiement plus tôt dans la journée. J'ai coordonné avec le DBA d'astreinte pour rediriger le trafic loin du réplica en retard pendant que nous faisions un rollback de la requête. L'incident a duré 40 minutes de la détection à la résolution. Tout au long, j'ai donné des mises à jour toutes les cinq minutes pour que l'équipe support puisse gérer les communications clients en parallèle. Après l'incident, j'ai écrit un post-mortem, ajouté une alerte de retard de réplication que nous n'avions pas, et ajouté l'analyse de performance des requêtes à notre checklist de pré-déploiement.

Nous devions ajouter des notifications en temps réel à notre plateforme. Deux approches étaient viables : le polling depuis le client toutes les quelques secondes, ou une connexion WebSocket par utilisateur. Le polling était plus simple à implémenter et plus facile à scaler horizontalement. Les WebSockets offraient une meilleure expérience utilisateur mais ajoutaient une complexité significative : état de connexion, logique de reconnexion, et configuration du load balancer. Étant donné notre base d'utilisateurs d'environ 50 000 utilisateurs actifs à l'époque, le polling aurait ajouté une charge significative sur la base de données pour une amélioration UX relativement faible. Nous avons choisi les WebSockets mais limité l'implémentation initiale à un sous-ensemble de types de notifications à haute valeur. Cela nous a permis de valider l'infrastructure avant de la déployer partout. La décision clé a été de construire une couche d'abstraction de notification pour pouvoir changer le mécanisme sous-jacent sans réécrire chaque consommateur.

J'ai hérité d'un service de reporting qui exécutait des traitements batch quotidiens et qui dépassait souvent le délai d'attente pour nos plus grands clients, parfois pendant quatre heures. J'ai profilé les requêtes les plus lentes et trouvé deux problèmes : une requête chargeait des tables entières en mémoire et filtrait dans le code applicatif plutôt qu'en SQL, et un job récurrent s'exécutait sans pagination et épuisait la mémoire sur les grands ensembles de résultats. J'ai réécrit la requête problématique pour utiliser des agrégats de base de données et des filtres indexés, et ajouté une pagination par curseur au job batch. Le résultat a été une réduction du temps d'exécution de quatre heures à moins de 20 minutes pour les plus grands comptes. J'ai aussi ajouté une alerte de délai pour être averti tôt si un futur job tendait dans la mauvaise direction.

SQL est mon choix par défaut pour la plupart des données applicatives car l'intégrité relationnelle, les transactions ACID et les requêtes ad hoc sont des propriétés précieuses que je ne veux pas sacrifier sans bonne raison. Je considère NoSQL quand l'une de ces trois conditions est vraie : les données sont véritablement de forme documentaire et ne bénéficient pas de la normalisation (un CMS à schéma variable en est un bon exemple) ; les patterns d'accès sont simples et connus à l'avance et j'ai besoin d'un scale horizontal plus facile à atteindre avec un magasin clé-valeur ou documentaire ; ou je construis un cas d'usage de séries temporelles ou de graphes qui s'adapte mal aux tables relationnelles. Ce que j'essaie d'éviter, c'est de choisir NoSQL pour des raisons de performance sans d'abord mesurer si la solution SQL est réellement trop lente. Les décisions d'architecture de base de données prématurées sont coûteuses à inverser.

La mise en cache est un compromis entre cohérence et performance, donc je commence par me demander si le cas d'usage tolère des données périmées, et si oui, pendant combien de temps. Pour les données qui changent peu fréquemment et sont lues par de nombreux utilisateurs comme la configuration, les données de référence ou les profils publics, un pattern cache-aside avec un TTL court est généralement le bon choix et Redis est mon outil par défaut. Pour les données où la cohérence est importante comme les soldes de comptes ou les niveaux de stock, j'évite le cache au niveau applicatif et me concentre sur l'optimisation de la requête. Je fais toujours attention à l'invalidation du cache : quand une écriture se produit, comment s'assurer que le cache ne sert pas de données périmées ? Je garde la logique d'invalidation simple et explicite plutôt que de me fier uniquement au TTL pour les données modifiées. J'instrumente aussi les taux de hit du cache : un cache en dessous de 70 % ne justifie généralement pas son poids.

J'aborde cela comme un problème d'analyse de charge. La question à laquelle je veux répondre avant de concevoir quoi que ce soit est : où le système se brise-t-il sous charge, et quel est le coût de chaque correctif ? Je commence par identifier le goulot d'étranglement probable : pour la plupart des applications web, c'est soit le pool de connexions à la base de données, soit une opération synchrone unique dans le chemin critique. Pour un scénario de pic, je pense à trois leviers. D'abord, le scaling horizontal : puis-je ajouter des instances derrière un load balancer sans état mutable partagé ? Ensuite, le découplage par file d'attente : puis-je déplacer le travail qui n'a pas besoin d'être synchrone dans une file pour que le temps de réponse de l'API reste rapide sous charge ? Troisièmement, les réplicas de lecture et la mise en cache : puis-je absorber le trafic de lecture sans toucher à la base de données primaire ? Une vraie décision d'architecture nécessite des données de tests de charge pour valider les hypothèses.