Une application de gestion qui sert des centaines d'utilisateurs a presque toujours un responsable applicatif, parfois appelé responsable d'application, gestionnaire d'applications ou application manager. Il connaît le paramétrage et les règles de gestion, pilote la TMA et l'éditeur, et répond au métier quand quelque chose ne va pas. Pour un responsable applicatif, les questions d'entretien gagnent à porter sur le run réel : incidents récurrents, versions, recette, flux et droits d'accès.
Le profil se trompe facilement sur CV. Un ancien technicien de support connaît le diagnostic mais n'a pas toujours piloté un prestataire ni préparé une version majeure. Un ancien consultant fonctionnel maîtrise le paramétrage et parfois moins l'exploitation. Le candidat décrit la dernière montée de version vécue, le nombre de jours de recette et ce qui a mal tourné.
Pour un poste sur un progiciel précis, deux ou trois questions portent sur ce produit, son paramétrage et son calendrier de versions. Le reste du métier se ressemble d'une application à l'autre. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Le périmètre technique d'un responsable applicatif
ITIL 4 : incidents, problèmes et changements
Le cadre ITIL 4, porté par PeopleCert qui propose aussi désormais ITIL (Version 5), décrit les pratiques que le responsable applicatif applique tous les jours. Un incident se rétablit vite, un problème cherche la cause d'incidents qui reviennent, un changement passe par une validation selon son risque. La certification ITIL 4 Foundation atteste le vocabulaire, l'expérience se vérifie sur des cas.
Outil ITSM
ServiceNow, Jira Service Management, GLPI ou EasyVista : les tickets des utilisateurs, de la TMA et de l'éditeur y passent. Le responsable applicatif y qualifie les demandes, suit les délais contractuels et en tire ses indicateurs mensuels. Reste à savoir quelles catégories il a créées et ce qu'il en a appris.
SQL et bases de données
Oracle, SQL Server ou PostgreSQL derrière la plupart des progiciels de gestion. Le responsable applicatif lit les tables pour comprendre une anomalie, rapprocher deux chiffres ou préparer une extraction. Il sait aussi où s'arrêter : une correction en base de production suit une procédure validée, souvent avec l'accord de l'éditeur.
Interfaces et flux
Fichiers déposés la nuit, API REST, EDI ou messages via un bus d'échanges relient l'application au reste du SI. Le responsable connaît chaque flux, son format, ses rejets et sa reprise. Une bonne part des incidents applicatifs naît dans ces échanges.
Ordonnanceur et traitements de nuit
Control-M, VTOM ou Dollar Universe lancent les traitements par lots : calculs, imports, exports, purges. Le responsable applicatif connaît leurs dépendances, leurs heures limites et la conduite à tenir quand l'un d'eux échoue, qu'il partage avec l'équipe d'exploitation.
Habilitations, annuaire et SSO
Les profils de l'application, reliés ou non à l'annuaire de l'entreprise (Active Directory, Microsoft Entra ID) et à une authentification unique en SAML ou OpenID Connect. Le responsable tient la matrice des profils, les règles de séparation des tâches et la revue périodique des comptes, que les auditeurs demandent souvent.
Environnements et outils de test
Recette, préproduction, formation : chaque environnement a ses données et ses règles. Les campagnes de non-régression se gèrent dans un outil comme Squash TM ou Xray, ou dans un tableur bien tenu. À chaque version, ces campagnes sont rejouées avec les key users.
Contrats de TMA et de maintenance éditeur
Délais de prise en charge et de correction par priorité, périmètre de la maintenance, durée de vie des versions, garantie sur les livraisons, unités d'œuvre consommées. Le responsable applicatif connaît ces clauses, parce qu'il s'en sert à chaque désaccord.
Le responsable applicatif travaille dans une DSI, rattaché à un responsable de domaine ou à un responsable des études, ou chez un prestataire qui tient la TMA d'un client. Il gère une application centrale ou un groupe d'applications plus petites, et ses journées se partagent entre le support de niveau 2, le suivi de la TMA et de l'éditeur, les évolutions et leur recette, les montées de version et les demandes des auditeurs. Les offres combinent souvent un produit (ITSM, MES, progiciel de paie ou de comptabilité) et des compétences communes : ITIL, SQL, pilotage de prestataires. Un responsable applicatif ERP, dont le périmètre couvre des processus de bout en bout, fait l'objet d'une fiche distincte.
Ce qu'un responsable applicatif doit maîtriser
- Incidents, problèmes et maintien en condition opérationnelle
- Montées de version et cycle de vie
- Évolutions, recette et non-régression
- Pilotage de la TMA et de l'éditeur
- Interfaces, données et diagnostic SQL
- Habilitations, sécurité et documentation
Cinq questions de run pour un responsable 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é
Depuis six semaines, la saisie bloque à chaque début de semaine et la TMA clôt le ticket à chaque fois. Que faites-vous ?
Une bonne réponseIl ouvre un problème distinct des incidents et regroupe les tickets. Il cherche ce qui se passe le week-end : un traitement par lots, une sauvegarde, une purge, un redémarrage, un changement récent. L'analyse de cause se fait avec la TMA et l'exploitation, le contournement est documenté comme erreur connue et la correction est planifiée. Il suit ensuite le nombre de récurrences, et demande à la TMA une analyse de cause pour tout incident répété.
Signal d'alerteRelancer la TMA à chaque ticket, ou accepter la clôture parce que le délai contractuel est respecté.
Question 2 · confirmé
L'éditeur sort une version majeure qui touche vos spécifiques et trois interfaces. Comment préparez-vous le passage ?
Une bonne réponseLecture des notes de version et des prérequis (système, base, navigateurs, composants), inventaire du paramétrage, des spécifiques et des interfaces touchés, installation sur un environnement de test, migration des données à blanc, campagne de non-régression avec les key users, plan de bascule et de retour arrière, formation et communication. La date évite les périodes sensibles du métier.
Signal d'alerteInstaller la version en recette une semaine avant la production, sans inventaire des spécifiques ni retour arrière prévu.
Question 3 · confirmé
Le métier envoie une demande d'une ligne : « ajouter un champ sur l'écran client ». Que faites-vous avant de la transmettre à la TMA ?
Une bonne réponseIl fait préciser le besoin : à quoi sert le champ, qui le saisit, d'où vient la donnée, où elle doit apparaître (états, exports, interfaces). Il vérifie si le paramétrage suffit, les impacts sur les flux et les rapports, et si la donnée est personnelle. Puis il écrit les règles de gestion et les critères d'acceptation, fait chiffrer et fait prioriser.
Signal d'alerteTransmettre la ligne telle quelle à la TMA, ou découvrir à la recette que le champ doit partir dans une interface.
Question 4 · confirmé
La TMA livre une correction qui casse une autre fonction en production. Comment réagissez-vous, et que changez-vous ensuite ?
Une bonne réponseD'abord le rétablissement : retour arrière de la livraison ou correctif, et information du métier. Puis l'analyse : tests de non-régression absents côté TMA, recette trop étroite côté client, environnement de test différent de la production. Ensuite des exigences écrites : rapport de tests joint à chaque livraison, correction sous garantie, indicateur de régressions suivi en comité.
Signal d'alerteAccuser la TMA sans regarder la recette interne, ou corriger soi-même en production.
Question 5 · confirmé
Depuis un mois, les chiffres de votre application ne correspondent plus à ceux de l'entrepôt de données. Comment cherchez-vous l'écart ?
Une bonne réponseIl fixe d'abord la définition et le périmètre (dates, statuts, filtres), puis compare des requêtes SQL des deux côtés à la même date. Il découpe par jour, par entité ou par type jusqu'à isoler l'écart, vérifie le flux d'alimentation (rejets, chargements partiels, suppressions non transmises) et les changements du mois (version, paramétrage, règle de calcul). Une fois la cause corrigée, il ajoute un contrôle de rapprochement automatique.
Signal d'alerteConclure que l'entrepôt a tort sans comparer, ou chercher dans les écrans de l'application sans requêter 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
Questions fréquentes sur le poste de responsable applicatif
Responsable applicatif ou technicien support applicatif : où passe la frontière ?
Le technicien support applicatif traite les tickets et diagnostique les anomalies, souvent sur le logiciel d'un éditeur pour ses clients. Le responsable applicatif répond de l'application dans la durée : il pilote la TMA et l'éditeur, décide des évolutions avec le métier, prépare les versions et tient les habilitations. Il fait aussi du diagnostic, mais son travail se mesure à la stabilité de l'application et à la qualité de ses relations avec les fournisseurs.
Un responsable applicatif doit-il savoir écrire du SQL ?
Oui, à un niveau de lecture solide : jointures, regroupements, rapprochement de deux sources. Sans SQL, il dépend de la TMA pour chaque diagnostic et perd du temps sur chaque incident. Il n'a pas besoin d'écrire des procédures stockées ni d'optimiser une base. Le point décisif est qu'il connaisse les règles avant de modifier des données de production.
Un test technique est-il prévu pour un responsable applicatif ?
Un exercice court suffit. L'exercice tient en deux ou trois tables simplifiées et un écart à expliquer, puis un extrait de comptes rendus de TMA à commenter. Le premier montre le diagnostic, le second la façon de piloter un prestataire. Il se fait en entretien plutôt qu'à la maison, pour suivre le raisonnement en direct.
La certification ITIL 4 Foundation est-elle utile pour ce poste ?
Elle donne un vocabulaire commun avec la production et le service desk : incident, problème, changement, erreur connue. Beaucoup d'offres la citent. Elle ne prouve pas la pratique : un problème réellement résolu et un changement urgent vécu en disent davantage. Un candidat sans certification mais avec ces exemples vaut mieux qu'un certifié qui n'en a aucun.
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.
