Questions d'entretien Responsable informatique

Je maintiens un backlog de demandes IT structuré et le revois mensuellement avec les parties prenantes business clés. Chaque demande entrante est évaluée sur trois dimensions : l'impact business (qu'est-ce qui se casse ou s'améliore si nous le faisons ou non ?), l'urgence (y a-t-il une échéance, une exigence de conformité ou un risque opérationnel qui conditionne le timing ?) et le niveau d'effort (combien de temps cela prendra-t-il réellement ?). Je catégorise le travail en trois compartiments : run (maintenir les activités), grow (améliorer les capacités existantes) et transform (changement stratégique). Le travail run est prioritaire par défaut car les pannes et interruptions affectent tout le monde immédiatement. Pour le travail grow et transform, j'utilise une matrice de notation et je présente la liste classée au comité de pilotage trimestriellement afin que les décisions de priorisation appartiennent au business, pas seulement à l'IT.

Je maintiens un registre des fournisseurs avec quatre données clés pour chaque fournisseur critique : date d'expiration du contrat, performance des SLA, contacts d'escalade et responsable du renouvellement. Je revois les performances des SLA mensuellement et tiens des revues business trimestrielles avec les fournisseurs critiques, pas seulement des renouvellements annuels de contrats. Je m'assure aussi de ne pas avoir une dépendance excessive envers un seul fournisseur pour un service critique : chaque fournisseur de niveau 1 doit avoir un plan de sortie documenté et une alternative testée. Avant de renouveler tout contrat significatif, j'effectue une revue concurrentielle légère, même si j'ai l'intention de renouveler, car cela me donne un levier de négociation sur les prix.

Je traite la sécurité comme un risque business, pas une responsabilité du département technique. Je maintiens un registre des risques avec probabilité, impact et état des mesures d'atténuation pour chaque risque IT identifié, et je le revois trimestriellement avec l'équipe dirigeante. Mon cadre de sécurité couvre quatre niveaux : sécurité périmétrique (pare-feux, détection d'intrusion), gestion des identités et des accès (moindre privilège, MFA partout), protection des données (chiffrement au repos et en transit, tests de sauvegarde et de récupération) et sensibilisation (simulations de phishing régulières et formation du personnel). J'effectue aussi un test d'intrusion annuel et traite toutes les conclusions critiques dans les 30 jours. La défaillance de sécurité la plus fréquente que je vois est celle d'organisations qui investissent dans des contrôles techniques mais négligent le facteur humain.

Nous avons subi une panne complète de notre plateforme client un mercredi après-midi, causée par une migration de base de données ratée. Le système était en panne pendant 90 minutes. J'ai activé immédiatement notre processus de réponse aux incidents : j'ai désigné un chef d'incident, mis en place un canal Slack dédié et établi un cycle de mise à jour de 15 minutes pour la communication avec les parties prenantes. J'ai tenu le PDG et le responsable du succès client informés avec des mises à jour en langage clair plutôt que des logs techniques. La cause principale était un script de migration non testé sur des volumes de données de production. Une fois restauré, j'ai conduit un post-mortem sans blame dans les 48 heures. Nous avons identifié trois lacunes de processus et les avons toutes traitées en une semaine. La disponibilité sur les 12 mois suivants a été de 99,97 %.

Notre PDG voulait migrer toute notre infrastructure de données vers une nouvelle plateforme cloud en six semaines, suite à une conversation lors d'une conférence. Le délai était irréaliste : une migration correcte nécessiterait six mois, une formation importante de l'équipe et comportait un risque élevé d'intégrité des données si elle était précipitée. J'ai préparé un document d'une page pour le PDG : un résumé de ce que la migration impliquerait réellement, le risque du délai de six semaines et un plan phasé alternatif qui livrait la première amélioration de capacité en huit semaines tout en gérant correctement le risque. J'ai présenté les deux délais côte à côte avec leur profil de risque. Le PDG a accepté le plan phasé. La migration s'est terminée avec succès en cinq mois.

Quand j'ai rejoint mon ancienne entreprise, l'IT était entièrement réactif : l'équipe passait 80% de son temps sur des tickets de support sans capacité pour des travaux d'amélioration. J'ai constaté que 40% du volume de tickets était causé par trois problèmes récurrents : une infrastructure d'imprimantes legacy, un VPN mal configuré et un processus d'intégration créant des problèmes d'accès pour les nouveaux employés. J'ai résolu les trois causes racines au cours du premier trimestre. Le volume de tickets a baissé de 38%, ce qui a libéré de la capacité pour un portail IT en libre-service réduisant les demandes par email de 60%, et un déploiement de gestion des appareils réduisant le temps de configuration des nouveaux entrants de 4 heures à 45 minutes. Au bout de six mois, l'équipe était passée de 80% réactive à 50% proactive.

Je maintiens une feuille de route infrastructure sur trois ans alignée avec le plan de croissance business. Tous les six mois je revois l'utilisation actuelle des ressources de calcul, stockage et réseau, et je modélise la demande future sur la base des prévisions d'effectifs, de la roadmap produit et du volume de transactions attendu. Je définis des seuils d'utilisation déclenchant une revue : si tout système de niveau 1 atteint 75% de capacité, je commence à planifier l'incrément suivant. Pour les ressources cloud j'utilise l'auto-scaling autant que possible pour éviter le sur-provisionnement. Pour l'infrastructure on-premises j'intègre un tampon de 20-25%. Je revois la feuille de route par rapport aux dépenses réelles trimestriellement et présente un résumé écrit au CFO.

J'utilise une classification des changements à trois niveaux : les changements standard (pré-approuvés, à faible risque, applicables à tout moment), les changements normaux (nécessitant une revue CAB, appliqués pendant une fenêtre de changement) et les changements d'urgence (contournant le processus normal mais nécessitant une revue post-implémentation dans les 24 heures). Chaque changement a une évaluation des risques, un plan de retour arrière et une approche de test définie avant de passer au CAB. Je tiens une réunion hebdomadaire du comité consultatif des changements de 30 minutes. Je maintiens aussi un calendrier de gel des changements pour les périodes critiques. La plus grande amélioration que j'ai apportée aux processus de changement est de rendre les plans de retour arrière obligatoires.

Je structure le budget IT en trois catégories qui correspondent à la valeur business : maintenir (garder les systèmes existants en fonctionnement, généralement 50-60% des dépenses IT), améliorer (gains d'efficacité et améliorations des capacités, généralement 30%) et innover (nouvelles capacités soutenant la croissance, généralement 10-20%). Je présente cette répartition à l'équipe dirigeante lors du budget car cela l'aide à comprendre que la plupart des dépenses IT sont un coût d'exploitation. Je suis aussi la valeur livrée par rapport au budget d'amélioration et d'innovation : pour chaque projet significatif je documente le résultat business attendu et rends compte du réel versus attendu à la clôture du projet.