---
title: "Guide d'entretien technique — Candidat 2 (Java/Spring/React)"
type: career
area: career
status: reference
interview_role: "Interviewer (Me)"
category: "Conducting Interview"
target_candidate: "Candidat 2 (Java/Spring)"
role: "Java / Spring / React Developer"
stage: "Technical Interview Assessment"
date: 2026-07-06
created: 2026-07-06
updated: 2026-07-06
tags:
  - career
  - conducting-interviews
---
# Guide d'entretien technique ciblé

Profil ciblé : candidat orienté Java / Spring / React avec usage de Python, Docker, GitLab CI et bases SQL, à évaluer pour un poste de maintenance et d'évolution sur FUSE et SECHEL / PROCURE.

## Objectif

- garder les questions utiles pour les apps à maintenir ;
- retirer les questions CV qui ne correspondent pas au résumé ;
- ajouter des questions liées aux projets personnels et au cursus du candidat ;
- fournir toutes les questions en français et en anglais ;
- mettre la réponse attendue directement sous chaque question ;
- finir par une grille de notes par partie de l'entretien, et non par question.

## Contexte des apps

### FUSE

- application Django de gestion de tâches sur 12 sites ;
- imports automatiques et manuels ;
- dashboard ;
- exports ;
- notifications ;
- liens entre tâches CMS / NVS / FUP ;
- PostgreSQL, Celery, JS/Webpack.

### SECHEL / PROCURE

- application Django de reporting planning pièces ;
- gros imports ;
- Pandas ;
- historique ;
- exports ;
- permissions ;
- MySQL, Celery, AWS / Terraform.

## Format recommandé - 75 à 90 minutes

- 10 min : parcours, cursus, projets personnels
- 25 min : Python / Django / imports / intégrité des données
- 20 min : questions spécifiques FUSE et SECHEL
- 15 min : exploitation, Celery, AWS, CI/CD
- 10 à 15 min : cas pratique final

## 1. Parcours, cursus et projets personnels

### Q1. Projet Django REST + React

**FR :** Vous avez développé une librairie en ligne avec Django REST Framework et React. Quelle partie avez-vous conçue vous-même côté backend, et comment avez-vous structuré les API, l'authentification et les relations métier ?

**EN:** You built an online bookstore with Django REST Framework and React. Which backend parts did you design yourself, and how did you structure the APIs, authentication, and domain relationships?

**Réponse attendue :**

- DRF avec modèles, serializers, vues/API ou ViewSets ;
- authentification claire ;
- validation côté backend ;
- pagination et séparation frontend/backend ;
- capacité à expliquer les relations métier et les choix de structure.

### Q2. Projet microservices personnel

**FR :** Sur votre projet personnel "Book-Micro", pourquoi avoir choisi une architecture microservices au lieu d'un monolithe, et qu'avez-vous appris sur la complexité réelle de ce choix ?

**EN:** In your personal "Book-Micro" project, why did you choose microservices instead of a monolith, and what did you learn about the real complexity of that choice?

**Réponse attendue :**

- justification du choix microservices ;
- compromis versus monolithe ;
- service discovery, communication inter-services, CI/CD, déploiement ;
- reconnaissance honnête de la complexité ajoutée.

### Q3. Projet OCR Python

**FR :** Vous avez développé un backend OCR avec Tesseract et Python. Comment validiez-vous la qualité du résultat, gérez-vous les erreurs d'extraction, et à quel moment refuseriez-vous une donnée reconnue automatiquement ?

**EN:** You built an OCR backend with Tesseract and Python. How did you validate output quality, handle extraction errors, and when would you reject automatically recognized data?

**Réponse attendue :**

- validation du résultat ;
- score de confiance ou règles de rejet ;
- nettoyage de données ;
- traitement des cas ambigus ;
- logs et traçabilité.

### Q4. Reporting à très gros volume

**FR :** Vous mentionnez une application de reporting avec 9 millions de lignes et un dashboard Grafana. Quelles optimisations concrètes avez-vous menées côté base, API ou agrégations ?

**EN:** You mention a reporting application handling 9 million records with a Grafana dashboard. What concrete optimizations did you make at the database, API, or aggregation layer?

**Réponse attendue :**

- travail sur index, plans SQL, agrégations, pagination ;
- réduction du volume transféré ;
- mesure avant/après ;
- approche méthodique et non intuitive.

### Q5. Cursus INPT

**FR :** Votre formation INPT en systèmes embarqués et services digitaux est plus large qu'un parcours purement web. Qu'est-ce que ce cursus vous apporte aujourd'hui dans la façon d'analyser un système de production ?

**EN:** Your INPT education in embedded systems and digital services is broader than a purely web-focused path. What does that background bring to the way you analyze a production system today?

**Réponse attendue :**

- rigueur analytique ;
- compréhension systèmes, réseaux, performance ;
- capacité à raisonner sur un système global et pas seulement sur le code.

## 2. Python, Django et fiabilité des traitements

### Q6. Transactions d'import

**FR :** Un import Excel met à jour plusieurs milliers d'objets Django. Une erreur survient après 70 % du traitement. Comment garantissez-vous la cohérence des données ?

**EN:** An Excel import updates several thousand Django objects. An error occurs after 70% of the processing. How would you guarantee data consistency?

**Réponse attendue :**

- `transaction.atomic` ;
- stratégie globale ou par lots selon volumétrie ;
- idempotence ;
- reprise ;
- journalisation et contraintes DB.

### Q7. Optimisation ORM

**FR :** Quelle différence existe-t-il entre `select_related()` et `prefetch_related()` ? Comment détecteriez-vous un problème N+1 ?

**EN:** What is the difference between `select_related()` and `prefetch_related()`? How would you detect an N+1 problem?

**Réponse attendue :**

- `select_related()` pour jointures FK / OneToOne ;
- `prefetch_related()` pour relations multiples ;
- diagnostic via logs SQL, toolbar, APM, tests ;
- détection d'un N+1 par répétition de requêtes.

### Q8. Concurrence sur une tâche

**FR :** Deux utilisateurs ou deux workers modifient en même temps la même tâche. Comment évitez-vous une mise à jour perdue ?

**EN:** Two users or workers update the same task at the same time. How do you prevent a lost update?

**Réponse attendue :**

- `select_for_update()` pour section critique ;
- `F()` pour mises à jour atomiques ;
- verrou optimiste via version ;
- update conditionnel ;
- protection des invariants en base.

### Q9. Permissions objet

**FR :** Comment implémenteriez-vous des permissions par objet pour limiter la visibilité d'une tâche selon le site, le rôle ou l'utilisateur ?

**EN:** How would you implement object-level permissions to restrict task visibility by site, role, or user?

**Réponse attendue :**

- filtrage serveur systématique ;
- cohérence entre vues, API, exports, tâches async ;
- pas de confiance au frontend ;
- tests d'autorisation.

### Q10. API d'import asynchrone

**FR :** Comment concevoir une API d'import qui peut durer plusieurs minutes sans bloquer la requête HTTP ?

**EN:** How would you design an import API that can take several minutes without blocking the HTTP request?

**Réponse attendue :**

- création rapide de ressource d'import ;
- lancement Celery ;
- réponse `202 Accepted` ;
- endpoint de statut ;
- idempotence.

### Q11. Validation de fichier avant écriture

**FR :** Comment valideriez-vous un fichier avant toute écriture en base : colonnes, types, références, doublons et règles métier ?

**EN:** How would you validate a file before writing to the database: columns, types, references, duplicates, and business rules?

**Réponse attendue :**

- validation multi-étapes ;
- colonnes attendues ;
- types ;
- références ;
- doublons ;
- règles métier ;
- rapport d'erreurs exploitable.

### Q12. Pandas et mémoire

**FR :** Un import Pandas fonctionne en local mais dépasse la mémoire en production. Que faites-vous ?

**EN:** A Pandas import works locally but runs out of memory in production. What do you do?

**Réponse attendue :**

- `usecols` ;
- dtypes explicites ;
- chunks ;
- éviter copies inutiles ;
- supprimer intermédiaires ;
- éventuellement changer d'approche si le volume dépasse la RAM.

### Q13. Historique fiable

**FR :** Comment garantir un historique fiable des changements de statut, d'affectation et d'origine d'une modification ?

**EN:** How would you guarantee a reliable audit history for status, assignment, and source-of-change updates?

**Réponse attendue :**

- audit généré côté serveur ;
- même transaction que la modification ;
- avant/après ;
- utilisateur ou process ;
- date ;
- source ;
- identifiant de corrélation.

## 3. Questions spécifiques FUSE et SECHEL

### Q14. Imports FUSE automatiques et manuels

**FR :** FUSE reçoit des imports automatiques réguliers et aussi des imports manuels ZIP. Comment concevriez-vous les garde-fous pour éviter qu'un fichier invalide ou incohérent corrompe les données ?

**EN:** FUSE receives regular automatic imports as well as manual ZIP imports. How would you design safeguards to prevent invalid or inconsistent files from corrupting data?

**Réponse attendue :**

- valider structure ZIP et fichiers attendus ;
- isoler les erreurs ;
- logs d'import ;
- rejet des fichiers incohérents ;
- protection contre corruption partielle.

### Q15. Gestion des conflits d'import FUSE

**FR :** FUSE détecte des conflits quand un UID importé ne correspond plus à la donnée déjà connue. Que faut-il stocker et afficher pour permettre à un utilisateur de décider entre Accept et Reject ?

**EN:** FUSE detects conflicts when an imported UID no longer matches known data. What should be stored and displayed so a user can safely choose Accept or Reject?

**Réponse attendue :**

- afficher ancienne valeur et nouvelle valeur ;
- source du fichier ;
- ligne ou identifiant concerné ;
- date et contexte ;
- impact métier de Accept / Reject ;
- traçabilité de la décision.

### Q16. Tâches importées en lecture seule

**FR :** Dans FUSE, certaines tâches importées doivent rester modifiables uniquement dans la source puis être réimportées. Comment faites-vous respecter cette règle côté backend et interface ?

**EN:** In FUSE, some imported tasks should only be editable in the source system and then re-imported. How would you enforce that rule in both backend and UI?

**Réponse attendue :**

- règle imposée côté backend ;
- champs bloqués ou objets read-only ;
- message clair dans l'UI ;
- protection API ;
- tests pour empêcher le contournement.

### Q17. Affectation, notifications et cohérence

**FR :** Une tâche est affectée à un consultant ou à un quality checker, avec notifications associées. Comment éviter les doublons de notification et garantir que l'état notifié correspond bien à l'état persistant ?

**EN:** A task is assigned to a consultant or quality checker, with notifications attached. How do you avoid duplicate notifications and ensure the notified state matches the persisted state?

**Réponse attendue :**

- émission d'événement après commit ;
- notifications idempotentes ;
- éviter les doublons sur retry ;
- audit de l'affectation ;
- cohérence stricte entre état sauvegardé et état notifié.

### Q18. Dashboard FUSE lent

**FR :** Le dashboard FUSE devient lent avec plusieurs millions de tâches. Quelle démarche de diagnostic appliquez-vous avant toute optimisation ?

**EN:** The FUSE dashboard becomes slow with several million tasks. What diagnostic process do you follow before optimizing anything?

**Réponse attendue :**

- mesurer avant d'optimiser ;
- distinguer frontend, backend et DB ;
- `EXPLAIN`, index, N+1, agrégations ;
- réduire les données transférées ;
- n'ajouter du cache qu'après diagnostic.

### Q19. Export volumineux

**FR :** Un export de données fait exploser la mémoire du conteneur. Comment corrigez-vous le problème sans juste augmenter la RAM ?

**EN:** A data export exhausts container memory. How do you fix it without simply increasing RAM?

**Réponse attendue :**

- streaming ou génération par chunks ;
- tâche async ;
- écriture progressive ;
- stockage externe type S3 ;
- lien temporaire ;
- ne pas juste augmenter la mémoire.

### Q20. Import SECHEL concurrent

**FR :** Dans SECHEL, un import Programme concurrent peut créer des doublons de POLines. Pourquoi un verrouillage base de données peut-il être préférable à un simple lock Celery ou Redis ?

**EN:** In SECHEL, concurrent Programme imports can create duplicate POLines. Why can a database lock be preferable to a simple Celery or Redis lock?

**Réponse attendue :**

- un verrou base protège l'état réel ;
- meilleure robustesse transactionnelle ;
- limites des verrous applicatifs Celery/Redis ;
- prévention des doublons à la source métier.

### Q21. Rejeu du même fichier

**FR :** Que doit-il se passer si le même fichier SECHEL est importé deux fois ?

**EN:** What should happen if the same SECHEL file is imported twice?

**Réponse attendue :**

- comportement métier explicite ;
- rejet, remplacement versionné ou import idempotent ;
- checksum ou identifiant métier ;
- contrainte anti-duplication.

### Q22. Traçabilité d'une donnée modifiée par import

**FR :** Un utilisateur affirme qu'une donnée a changé après un import. Quelles informations doivent être disponibles pour enquêter rapidement ?

**EN:** A user claims a value changed after an import. What information should be available to investigate quickly?

**Réponse attendue :**

- fichier source ou empreinte ;
- utilisateur ou worker ;
- date ;
- paramètres d'import ;
- anciennes et nouvelles valeurs ;
- logs ;
- identifiant de tâche ;
- version applicative.

### Q23. MySQL et PostgreSQL

**FR :** SECHEL utilise MySQL alors que FUSE utilise PostgreSQL. Quelles différences surveilleriez-vous si vous deviez corriger le même bug ou porter un composant d'une app à l'autre ?

**EN:** SECHEL uses MySQL while FUSE uses PostgreSQL. What differences would you watch if you had to fix the same bug or port a component from one app to the other?

**Réponse attendue :**

- différences de types ;
- collations ;
- JSON ;
- nulls ;
- index ;
- plans d'exécution ;
- verrouillage ;
- SQL spécifique.

### Q24. Petite feature frontend sur app legacy

**FR :** Les apps sont surtout server-rendered Django avec JS/Webpack existant, pas une SPA React complète. Comment aborderiez-vous l'ajout d'une petite feature UI sans sur-architecturer le frontend ?

**EN:** These apps are mostly server-rendered Django apps with existing JS/Webpack, not full React SPAs. How would you add a small UI feature without over-engineering the frontend?

**Réponse attendue :**

- respecter l'architecture existante ;
- JS ciblé ;
- contrat backend simple ;
- progressive enhancement ;
- éviter de réintroduire une SPA inutilement.

## 4. Exploitation, Celery, AWS et CI/CD

### Q25. Tâches Celery rejouées

**FR :** Une tâche Celery s'exécute deux fois après redémarrage d'un worker. Comment évitez-vous les doublons fonctionnels ?

**EN:** A Celery task runs twice after a worker restart. How do you prevent functional duplicates?

**Réponse attendue :**

- idempotence ;
- identifiant métier ;
- contrainte DB ;
- vérification d'état dans transaction ;
- ne pas se reposer seulement sur l'ID Celery.

### Q26. Retry

**FR :** Quand faut-il réessayer automatiquement une tâche, et quand faut-il échouer immédiatement ?

**EN:** When should a task be retried automatically, and when should it fail immediately?

**Réponse attendue :**

- retry sur erreurs transitoires ;
- pas de retry aveugle sur erreur métier ou données invalides ;
- backoff exponentiel ;
- limite de tentatives ;
- alerte ou dead-letter handling.

### Q27. Redis partagé

**FR :** Quels risques voyez-vous à partager une même instance Redis entre cache, broker Celery et autres usages temps réel ?

**EN:** What risks do you see in sharing one Redis instance between cache, Celery broker, and other real-time usages?

**Réponse attendue :**

- contention CPU/mémoire ;
- éviction ;
- panne commune ;
- saturation ;
- manque d'isolation ;
- surveillance dédiée requise.

### Q28. ECS / AWS

**FR :** Décrivez le trajet d'une requête HTTPS vers une application Django exécutée sur ECS.

**EN:** Describe the path of an HTTPS request to a Django application running on ECS.

**Réponse attendue :**

- DNS ;
- ALB ;
- TLS ;
- listener ;
- target group ;
- security groups ;
- tâche ECS ;
- application ;
- logs et health checks.

### Q29. Diagnostic ECS

**FR :** Une tâche ECS démarre puis est continuellement remplacée. Où cherchez-vous la cause en premier ?

**EN:** An ECS task starts and is continuously replaced. Where do you investigate first?

**Réponse attendue :**

- événements ECS ;
- raison d'arrêt ;
- logs conteneur ;
- health checks ;
- secrets ;
- réseau ;
- CPU / mémoire ;
- commande de démarrage.

### Q30. Kubernetes vers ECS / Terraform

**FR :** Vous avez plus d'expérience Kubernetes que Terraform/ECS. Comment transposeriez-vous vos réflexes DevOps pour être rapidement efficace sur ce stack ?

**EN:** You have more Kubernetes experience than Terraform/ECS. How would you transfer your DevOps instincts to become effective quickly on this stack?

**Réponse attendue :**

- transférer les concepts de déploiement, health checks, observabilité, rollback, sécurité ;
- lire l'infra existante avant d'agir ;
- reconnaître les différences d'outillage ;
- capacité d'apprentissage pragmatique.

### Q31. GitLab CI/CD

**FR :** Les projets s'appuient sur GitLab CI/CD. Comment structureriez-vous un pipeline simple mais sûr pour test, build et déploiement ?

**EN:** The projects rely on GitLab CI/CD. How would you structure a simple but safe pipeline for test, build, and deployment?

**Réponse attendue :**

- stages clairs ;
- séparation test / build / deploy ;
- gestion des artefacts ;
- gestion saine des secrets ;
- règles sur branches/environnements ;
- stratégie de rollback.

## 5. Cas pratique final

### Q32. Incident combiné sur app de production

**FR :**

Après un déploiement de SECHEL :

- le site répond lentement ;
- certaines tâches Celery s'exécutent deux fois ;
- la mémoire du service augmente ;
- un import a été relancé par un utilisateur ;
- aucun test CI n'a échoué.

Expliquez votre démarche pendant les 30 premières minutes.

**EN:**

After a SECHEL deployment:

- the site is slow;
- some Celery tasks run twice;
- service memory usage increases;
- a user re-ran an import;
- no CI test failed.

Explain what you would do during the first 30 minutes.

**Réponse attendue :**

- stabiliser le service ;
- stopper ou limiter le rollout si nécessaire ;
- comparer avec la version précédente ;
- analyser logs, workers, métriques, ECS, DB ;
- vérifier rejeu, concurrence et idempotence des imports ;
- conserver les preuves avant redémarrage ;
- rollback si besoin ;
- corriger puis ajouter test/alerte.

## Grille de notation par partie

Noter chaque partie de 0 à 4 :

- **0 :** aucune maîtrise
- **1 :** notions faibles
- **2 :** réponse correcte mais peu pratique
- **3 :** bonne maîtrise avec exemples concrets
- **4 :** très bon niveau, raisonnement structuré, compromis clairs

| Partie | Note /4 | Observation |
| --- | --- | --- |
| Parcours, cursus, projets personnels | ____ / 4 | ______________________________ |
| Python / Django / intégrité des données | ____ / 4 | ______________________________ |
| Maintenance FUSE / SECHEL | ____ / 4 | ______________________________ |
| DevOps / Celery / AWS / CI-CD | ____ / 4 | ______________________________ |
| Diagnostic et résolution d'incident | ____ / 4 | ______________________________ |
| Communication et clarté | ____ / 4 | ______________________________ |

## Synthèse finale

| Critère | Observation |
| --- | --- |
| Points forts | ______________________________ |
| Risques / gaps | ______________________________ |
| Capacité à monter en compétence sur Django | ______________________________ |
| Capacité à maintenir FUSE / SECHEL | ______________________________ |
| Décision finale | Favorable / A discuter / Défavorable |
Note :
Ingénieur Data, Portnet digitalise le process des import export au Maroc