Ce qui est demandé lors d'un entretien d'analyste système, comment répondre sur les exigences, les intégrations et les schémas, et comment répéter la conversation.
L'analyste système n'est pas évalué sur sa connaissance des notations, mais sur sa capacité à transformer une demande floue du métier en exigences sur lesquelles l'équipe pourra travailler. C'est pourquoi la moitié des questions ressemble à « que ferez-vous si… » plutôt qu'à « dessinez un diagramme ».
| Étape | Ce qui est évalué |
|---|---|
| Présélection | expérience, domaines, attentes salariales |
| Théorie de l'analyse | exigences, notations, documentation |
| Étude de cas ou tâche | comment vous clarifiez et analysez la situation |
| Intégrations et données | API, SQL, formats, gestion des erreurs |
| Rôle dans l'équipe | conflits, frontières avec le PM et le développement |
On attend un processus, pas « je discute avec le client » : par quoi commencez-vous, quelles questions posez-vous, comment consignez-vous, comment vérifiez-vous que vous avez bien compris. Une bonne réponse contient des artefacts : liste de questions, prototype, schéma, critères d’acceptation.
Question classique : nommer les exigences non fonctionnelles d’un système. On vérifie si vous pensez aux performances, à la charge, à la disponibilité, à la sécurité, à l’ergonomie et aux contraintes de l’environnement.
BPMN versus diagramme d’activité UML, à quoi sert un flow-chart, comment décrire un état (state machine). Il est important non seulement de connaître la notation, mais aussi d’expliquer quand l’utiliser et quand une liste d’étapes suffit.
REST contre GraphQL et gRPC, idempotence, versionnage, délais d’attente et nouvelles tentatives, files d’attente et garanties de livraison. On donne souvent le cas : « le service répond avec du retard — que faire ».
JOIN, index, normalisation, agrégats. On demande généralement d’écrire une requête en mots ou d’analyser une requête lente.
Ce que comprend la spécification, qui la lit, comment la maintenir à jour. On apprécie la capacité à écrire de manière à ce que le développeur ne vienne pas avec des questions.
En quoi l’analyste diffère du product manager, qui priorise, qui est responsable de la recette. C’est une question de maturité et de capacité à s’accorder sur les zones de responsabilité.
Le cas est l'étape principale. La même structure fonctionne : clarification → décomposition → options → choix avec justification → risques.
« Avant de proposer une solution, je vais clarifier trois choses : qui sont les utilisateurs, quel est le volume de données et ce qui est considéré comme un succès. Ensuite, je décomposerai en sous-systèmes — réception de la demande, traitement, notification. J'examinerai deux options : l'appel synchrone et la file d'attente. Je choisirai la file d'attente si un délai est acceptable, — sinon nous perdrons lors des pics de charge. Risque : sans supervision, la file d'attente augmentera sans qu'on le remarque. »
L'intervieweur n'écoute pas la réponse, mais le processus : clarifiez-vous avant de décider, et voyez-vous les limites de votre variante.
Une semaine à raison de 30–40 minutes : passer en revue sept sujets, se remémorer deux ou trois de ses projets avec des chiffres et dérouler un cas à voix haute une fois. Le cas compte plus que la théorie — c’est souvent là que les candidats sont éliminés.
Connaître au moins une notation — oui, mais lors de l’entretien, on n’évalue pas le dessin, mais la capacité à expliquer un schéma avec des mots et à choisir le bon niveau de détail. Il suffit souvent de savoir décrire un processus sous forme de liste d’étapes et d’états.
Dites-le franchement et posez des questions — c’est précisément le travail de l’analyste. « Je n’ai jamais travaillé dans la logistique, mais pour comprendre, je poserai des questions sur X, Y, Z » sonne plus professionnel qu’une tentative de deviner.
Presque toujours, au moins au niveau des JOIN et des agrégats. Souvent, on ne demande pas d’écrire une requête, mais d’expliquer comment vous la construiriez et pourquoi vous avez choisi cette approche.
Par une fourchette et en s’appuyant sur le marché. Analyse détaillée dans l’article négociation salariale.
Décrivez la situation en une phrase — « entretien analyste système, intégrations, trois ans d'expérience » — et menez le dialogue dans le simulateur. Le formateur posera des questions sur votre rôle et analysera les réponses après la conversation.
Prenez deux de vos projets et décrivez-les selon le schéma : tâche — ce que vous avez clarifié — quelle solution vous avez choisie — comment cela s'est terminé. Ensuite, déroulez le cas à voix haute : ouvrez HintMeTalk AI, mode « Coach », décrivez le poste en une phrase. Après l'analyse, on voit où vous commencez à résoudre sans avoir posé de question.
La préparation générale se trouve dans l'article préparation à l'entretien, . Analyses pour d'autres rôles : front-end et Python.
Entraînez cette compétence dans HintMeTalk AI
Ouvrir l’app
HintMeTalk