Chaque direction métier a en face d'elle, à la DSI, un interlocuteur qui répond de ses applications : c'est le responsable de domaine SI, aussi appelé responsable de domaine applicatif ou manager de domaine. Il arbitre la demande de ce métier, défend son budget, suit les éditeurs et les prestataires du périmètre et garde la cohérence avec l'architecture d'entreprise. Préparer des questions d'entretien pour un responsable de domaine SI, c'est donc couvrir à la fois la relation avec le métier, l'argent et la technique des flux.
Deux profils se présentent souvent. L'ancien consultant fonctionnel ou chef de projet progiciel connaît les processus, parfois moins le budget et le run. L'ancien responsable d'application maîtrise l'exploitation, et doit encore montrer qu'il sait construire une feuille de route sur trois ans et la vendre à un comité de direction.
Le domaine couvert change le vocabulaire, pas les questions. Pour un domaine finance, l'échange porte sur la clôture ; pour un domaine supply, sur les flux d'entrepôt. Le candidat raconte une feuille de route réellement présentée et ce que le métier en a retenu. Le PDF propose 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Ce que gère un responsable de domaine SI au quotidien
Cartographie applicative et outils d'architecture
La carte des applications du domaine, des processus qu'elles servent et des flux qui les relient. Elle se tient dans un outil comme SAP LeanIX ou Bizzdesign Hopex (ex-MEGA), ou plus modestement dans un tableur relié à la CMDB. Le candidat doit expliquer comment il l'a tenue à jour et à quelles décisions elle a servi.
Urbanisation et TOGAF
L'urbanisation découpe le SI en zones et en quartiers, et fixe où se trouve chaque donnée de référence. TOGAF, publié par The Open Group, donne une méthode d'architecture d'entreprise. Le responsable de domaine n'est pas architecte, mais il applique ces principes dans son périmètre et sait quand faire intervenir le comité d'architecture.
Progiciels, ERP et SaaS
La plupart des domaines reposent sur un progiciel central, un ERP ou un SaaS, entouré d'applications plus petites. Le responsable suit la feuille de route de l'éditeur, les mises à jour imposées et les fins de maintenance, comme les migrations de SAP ECC vers S/4HANA. Chaque développement spécifique ajouté au progiciel alourdit ces mises à jour.
Flux et plateforme d'intégration
Fichiers de nuit, API, messages ou EDI relient les applications du domaine entre elles et avec les autres domaines. Une plateforme d'intégration (ESB, iPaaS) centralise souvent ces échanges. Le responsable connaît les flux critiques, leur supervision et le propriétaire de chaque donnée échangée.
Budget du domaine et coût complet
Le budget du domaine rassemble le run (abonnements, licences, maintenance, hébergement, TMA, temps interne) et le build (projets et évolutions). Le coût complet d'une application, rapporté au nombre d'utilisateurs, sert à décider de la garder, de la remplacer ou de la retirer. Les hausses d'abonnements SaaS se discutent au renouvellement de chaque contrat.
Engagements de service et satisfaction
Disponibilité, délais de prise en charge et de résolution, périodes critiques comme une clôture ou une campagne commerciale : les engagements se fixent avec le métier selon la criticité de chaque application. La satisfaction se mesure par enquête, par l'analyse des tickets et par le réseau des key users.
Gestion de la demande et outils de portefeuille
Les demandes du métier passent par un outil de portefeuille ou de tickets, Jira, ServiceNow SPM, Planisware ou un équivalent maison. Le responsable de domaine les qualifie, les chiffre avec son équipe et les fait arbitrer en comité. L'outil compte moins que la règle d'arbitrage connue de tous.
Sécurité, RGPD et contrats de sous-traitance
Chaque application du domaine traite des données à classer, à protéger et parfois à déclarer au registre des traitements. Pour un SaaS, le contrat doit comporter les clauses de sous-traitance prévues par l'article 28 du RGPD, et la localisation des données se vérifie avant signature. Le responsable associe le RSSI et le DPO dès l'instruction.
Le poste existe surtout dans les DSI de taille moyenne et grande, organisées par domaines métier. Le responsable de domaine SI rend compte au DSI, au DSI adjoint ou au responsable des études, et encadre selon les cas des chefs de projet, des responsables d'application et des prestataires. Sa journée se partage entre les comités avec le métier, le suivi des projets, le run et le budget. Dans certaines organisations, une partie de la relation avec le métier revient à un IT business partner, et le responsable de domaine se concentre alors sur la livraison et le run. Les offres demandent en général une expérience de pilotage de projets ou de domaine dans une DSI, un cabinet de conseil ou un intégrateur.
Les compétences d'un responsable de domaine SI à vérifier
- Feuille de route et vision du domaine
- Arbitrage de la demande métier
- Budget du domaine, run et build
- Applications, flux et architecture
- Qualité de service et fournisseurs
- Management de l'équipe et gouvernance
Cinq situations de domaine en entretien
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 · senior
Le directeur financier, votre client interne, veut « un SI finance moderne » dans trois ans. Comment transformez-vous cette demande en feuille de route ?
Une bonne réponseIl commence par les processus et leurs irritants mesurés (délai de clôture, saisies manuelles, rapprochements), puis l'état du parc : applications, versions, contrats, flux. Il propose des options chiffrées, découpe en vagues avec des bénéfices attendus par vague, vérifie les dépendances avec les autres domaines et la capacité de l'équipe. La feuille de route est validée en comité et revue chaque trimestre.
Signal d'alerteUne liste d'outils à acheter, ou un grand programme sans jalons ni bénéfices mesurables.
Question 2 · confirmé
Le métier veut un développement spécifique pour retrouver dans le nouveau progiciel une règle de gestion de l'ancien outil. Comment tranchez-vous ?
Une bonne réponseD'abord comprendre la règle : obligation légale, besoin réel ou habitude. Puis comparer les options : processus adapté au standard, paramétrage, extension par les points prévus par l'éditeur, spécifique. Le coût du spécifique inclut ses tests à chaque mise à jour. Le propriétaire du processus décide en voyant ce coût, et l'écart est inscrit dans un registre des écarts au standard.
Signal d'alerteAccepter tous les spécifiques pour éviter le conflit, ou les refuser tous par principe.
Question 3 · senior
Le run de votre domaine augmente de 12 % par an alors que votre budget reste stable. Où cherchez-vous les économies ?
Une bonne réponseIl décompose le coût par application et par poste : abonnements et indexations, licences, maintenance, hébergement, TMA, temps interne. Puis il cherche les licences inutilisées, les applications peu utilisées à retirer, les niveaux de service surdimensionnés, les contrats à renégocier avant leur préavis et la dette qui génère des incidents. Il chiffre chaque piste et son délai.
Signal d'alerteCouper les projets pour financer le run, ou demander une hausse de budget sans analyse.
Question 4 · confirmé
Votre domaine compte 25 applications reliées par une soixantaine d'interfaces, dont la moitié par fichiers de nuit. Que faites-vous de cette cartographie ?
Une bonne réponseIl décrit chaque flux : source, cible, données, fréquence, technologie, propriétaire, supervision. Il repère les données de référence et leur application maître, les flux critiques sans supervision et les points uniques de défaillance. Les flux passent en API ou en événements quand le métier a besoin de fraîcheur, et les fichiers restent là où ils suffisent. Le tout en lien avec l'architecte d'entreprise.
Signal d'alerteTout passer en API par principe, ou ne pas savoir quels flux sont critiques.
Question 5 · confirmé
Pendant la clôture mensuelle, l'application de consolidation tombe pendant quatre heures. Que faites-vous pendant l'incident, puis la semaine suivante ?
Une bonne réponsePendant : une cellule avec la production et l'éditeur, une information régulière des utilisateurs avec une estimation de reprise, un contournement si possible, et la décision avec le métier de décaler une échéance. Après : une revue post-incident, la recherche de la cause racine en gestion des problèmes, des actions datées, et un calendrier des périodes sensibles avec gel des changements et vigilance renforcée.
Signal d'alerteAttendre que la production règle le problème sans prévenir le métier, ou clore l'incident sans chercher la cause.
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
Responsable de domaine SI : les questions fréquentes
Responsable de domaine SI ou responsable applicatif : qui fait quoi ?
Le responsable applicatif tient une ou quelques applications au quotidien : incidents, évolutions, montées de version, relation avec l'éditeur et la TMA. Le responsable de domaine SI pilote l'ensemble des applications d'un domaine métier, leur feuille de route et leur budget, et encadre souvent les responsables applicatifs. Le second négocie avec la direction métier, le premier avec les utilisateurs et les fournisseurs. Les deux postes se recrutent sur des critères différents.
Faut-il connaître le métier du domaine pour réussir dans ce poste ?
Une bonne connaissance des processus du domaine fait gagner plusieurs mois et donne du crédit face à la direction métier. Elle s'acquiert pourtant, alors que la capacité à arbitrer, à tenir un budget et à piloter des fournisseurs se vérifie plus difficilement. Pour un domaine très réglementé, comme la paie ou la comptabilité, une expérience du domaine est exigée ; ailleurs, la méthode prime.
Les questions changent-elles selon le domaine couvert ?
Les questions restent les mêmes : feuille de route, arbitrage, budget, flux, qualité de service, équipe. Seul le contexte change. Pour un domaine finance, les mises en situation portent sur la clôture et la consolidation ; pour un domaine supply, sur les flux d'entrepôt et de transport ; pour un domaine RH, sur la paie et la confidentialité. Le cas de 20 minutes s'adapte aussi au progiciel réellement en place.
Comment mettre un responsable de domaine SI en situation sans test technique ?
Le candidat reçoit une cartographie simplifiée du domaine, un extrait de budget et trois demandes métier concurrentes, puis propose une feuille de route sur un an et la façon de la présenter au comité. Il arbitre à voix haute. On voit en vingt minutes s'il raisonne en processus et en coûts ou s'il récite une méthode.
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.
