Un poste de support applicatif se situe entre le client et l'équipe qui code. Le technicien, souvent appelé analyste support applicatif en N2 ou N3, connaît le logiciel métier côté fonctionnel (ERP, WMS, paie, trésorerie, logiciel d'un éditeur) et va voir ce qui se passe derrière l'écran. Les questions d'entretien partent de ce geste : interroger la base, lire un journal, rejouer un appel d'API.
Les CV se ressemblent beaucoup. « Bonnes bases SQL » peut vouloir dire un SELECT recopié d'une procédure ou une vraie requête de diagnostic avec jointures et agrégats. « Support N2 » peut cacher un poste de transfert d'appels. Le candidat raconte une anomalie récente : ce qu'elle produisait à l'écran, ce que la personne a cherché, dans quelle table, dans quel fichier de log. Un profil solide cite des noms de tables et des messages d'erreur précis.
Le rapport à la production compte aussi. Le bon réflexe est la lecture d'abord, la correction en base seulement avec une procédure, un script relu et une trace. Le PDF ajoute un cas de 20 minutes sur des factures envoyées en double.
Ce qu'un technicien support applicatif ouvre dans sa journée
Le logiciel métier
ERP, WMS, logiciel de paie, de trésorerie ou progiciel d'un éditeur : c'est l'objet du poste. Le technicien doit en connaître les écrans, le paramétrage et les règles de gestion pour dire si un comportement est une anomalie ou un usage imprévu. Chez un éditeur, il connaît aussi les différences entre versions.
SQL (Oracle, SQL Server, PostgreSQL)
La base de données est le premier endroit où l'on vérifie ce que l'écran affiche. Le technicien écrit des requêtes de lecture avec jointures, regroupements et filtres sur des dates. La modification directe en base reste rare et encadrée par une procédure.
Journaux applicatifs et centralisation
Fichiers de log du serveur d'application, Observateur d'événements sous Windows, ou outil central comme Kibana, Splunk ou Graylog. Savoir filtrer par heure et par utilisateur, puis lire une pile d'appels jusqu'à la première exception, fait gagner des heures.
Outil de ticketing
ServiceNow, Jira Service Management, GLPI ou EasyVista. Le technicien y qualifie, priorise, relie les tickets entre eux et documente sa résolution. La qualité d'écriture d'un ticket se juge sur pièce, sur un exemple anonymisé.
API et formats d'échange
Beaucoup d'anomalies viennent des échanges avec d'autres logiciels : API REST en JSON, services SOAP en XML, fichiers plats CSV déposés en SFTP. Postman ou curl servent à rejouer un appel, et les codes HTTP disent déjà beaucoup sur la cause.
Serveurs Linux et Windows
Le technicien n'administre pas les serveurs, mais il doit s'y repérer : tail, grep et journalctl sous Linux, services et journaux d'événements sous Windows, serveurs d'application comme Tomcat ou IIS. Sans ces bases, chaque recherche passe par l'équipe système.
Ordonnanceur et traitements de nuit
Control-M, VTOM, Automic ou une simple crontab lancent les imports, exports et calculs nocturnes. Le support applicatif lit le statut d'un traitement et son journal, et ne relance qu'en suivant la consigne d'exploitation.
Environnements et versions
Recette, préproduction et production, avec leurs numéros de version et leurs notes de livraison. Rapprocher la date d'apparition d'un bug de la dernière mise en production est souvent la piste la plus rapide.
Le poste existe chez les éditeurs de logiciels, dans les DSI qui exploitent des applications métier et dans les ESN qui assurent la maintenance applicative pour un client. Les intitulés varient : technicien, analyste, consultant ou ingénieur support applicatif, avec un niveau N1, N2 ou N3 qui change beaucoup le contenu. En N1, on qualifie et on applique des procédures. En N2, on diagnostique en base et dans les journaux. En N3, on lit parfois le code et on propose le correctif. L'offre précise le niveau, et les questions y correspondent.
Les compétences techniques à contrôler en support applicatif
- Requêtes SQL de diagnostic
- Lecture des journaux applicatifs
- Reproduction et qualification d'anomalies
- API, interfaces et fichiers d'échange
- Tickets exploitables par les développeurs
- Versions, environnements et traitements de nuit
Cinq questions d'entretien d'analyste support applicatif
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un client signale qu'une commande saisie hier n'apparaît pas dans son écran de suivi. Quelles requêtes lancez-vous avant d'escalader ?
Une bonne réponseIl retrouve d'abord la commande en base par sa référence, la date et l'utilisateur qui l'a saisie, puis regarde son statut et les tables liées (lignes, client, site). Il la compare à une commande qui s'affiche bien et vérifie les filtres de l'écran : site, période, droits du profil. Il travaille en lecture seule, avec un WHERE précis, sur un compte qui ne peut pas modifier la production.
Signal d'alerteUne escalade immédiate sans aucune vérification, ou un UPDATE lancé pour « remettre le bon statut ». Un SELECT * sans filtre sur une table de quelques millions de lignes en pleine journée.
Question 2 · junior à confirmé
Une erreur 500 apparaît quand l'utilisateur valide un formulaire. Dans quels journaux cherchez-vous, et avec quels outils ?
Une bonne réponseIl demande l'heure exacte et l'identifiant de l'utilisateur, puis ouvre le journal du serveur applicatif (Tomcat, IIS, le fichier de log de l'application) ou l'outil de centralisation (Kibana, Splunk, Graylog). Il filtre sur l'heure et l'utilisateur, remonte la pile d'appels jusqu'à la première exception et distingue une erreur technique (délai dépassé vers la base, valeur nulle) d'une règle métier mal gérée.
Signal d'alerte« Je redémarre le serveur », ou une analyse limitée au message affiché à l'écran.
Question 3 · confirmé
Une anomalie ne se reproduit qu'en production, jamais en recette. Comment avancez-vous ?
Une bonne réponseIl compare ce qui diffère entre les deux environnements : version déployée, paramétrage, droits du profil utilisateur, interfaces branchées seulement sur la production, et surtout les données (un caractère spécial, un volume, un cas que la recette ne contient pas). Il recrée ce cas en recette avec des données anonymisées et note les étapes exactes qui déclenchent l'erreur.
Signal d'alerte« Non reproductible, ticket clos », ou des tests répétés en production sur les données du client.
Question 4 · confirmé
Le fichier d'import qu'un partenaire envoie chaque nuit est rejeté depuis deux jours. Que vérifiez-vous ?
Une bonne réponseLe rapport de rejet ou le journal de l'interface, puis le fichier lui-même : encodage (UTF-8, Windows-1252, présence d'un BOM), séparateur, en-tête, nombre de colonnes, format des dates et des montants. Il compare avec le fichier d'une nuit où tout s'est bien passé, ligne à ligne s'il le faut. Il vérifie aussi l'arrivée du fichier (nom attendu, dépôt SFTP, horaire) et relance le traitement après correction sans créer de doublons.
Signal d'alerteCorriger le fichier à la main et le réinjecter sans trace ni accord, ou ne jamais penser à l'encodage.
Question 5 · junior à confirmé
Vous transmettez une anomalie à l'équipe de développement. Que met-on dans le ticket ?
Une bonne réponseL'environnement et la version, les étapes numérotées pour reproduire, le résultat attendu et le résultat obtenu, les identifiants des données concernées, l'extrait de journal horodaté et la requête SQL qui montre l'état en base. Il ajoute l'impact (nombre d'utilisateurs, processus bloqué), le contournement proposé au client et une priorité argumentée.
Signal d'alerte« Ça ne marche pas chez le client, voir capture » ; un ticket que le développeur doit rouvrir pour demander la version ou les données.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Support applicatif : questions fréquentes
Quelle différence entre un technicien support applicatif et un technicien helpdesk ?
Le technicien helpdesk traite le poste de travail et les outils courants : compte bloqué, Outlook, imprimante, VPN. Le support applicatif s'occupe d'un logiciel métier précis et va chercher la cause dans sa base de données, ses journaux et ses interfaces. Il travaille avec les développeurs ou l'éditeur, pas avec l'équipe système. Un bon technicien helpdesk peut évoluer vers ce poste s'il apprend le SQL et le fonctionnement du logiciel concerné.
Quel niveau de SQL est attendu d'un analyste support applicatif ?
Pour un N2, des requêtes de lecture écrites sans modèle : jointures internes et externes, GROUP BY avec HAVING, filtres sur des dates, recherche de doublons. Il doit aussi connaître les risques d'une requête lourde sur une base de production. Pour un N3, s'y ajoutent la lecture d'un plan d'exécution et l'écriture d'un script de correction encadré par une transaction. Un N1 peut se contenter de lancer des requêtes déjà rédigées.
Faut-il un test technique pour un poste de support applicatif ?
Un exercice court en entretien suffit et dit beaucoup. À partir de deux ou trois tables simplifiées et d'un extrait de journal, le candidat explique pourquoi une commande n'apparaît pas à l'écran. En vingt minutes, on voit la requête écrite, la lecture du journal et l'ordre des vérifications. Il rédige ensuite le ticket pour les développeurs : la clarté de ce texte compte autant que le diagnostic.
Un profil fonctionnel sans bagage technique peut-il tenir le poste ?
Oui en N1, quand le travail consiste surtout à expliquer le logiciel, à reproduire un cas et à appliquer des procédures. En N2 et au-delà, il lui faudra apprendre le SQL et la lecture des journaux. Une connaissance fine du métier (paie, logistique, comptabilité) reste un vrai atout, car elle permet de dire vite si un résultat est faux. L'entretien vérifie que la personne a déjà ouvert une base, même en lecture.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
