RSSI externalisé vs DSI : qui fait quoi ?
23 septembre 2026
Dans beaucoup de PME et d’ETI françaises, la question de la cybersécurité atterrit par défaut sur le bureau du DSI, simplement parce qu’il est déjà là et qu’il n’y a personne d’autre à qui la confier. Cette logique fonctionne un temps, jusqu’au jour où un audit, un client exigeant, une obligation NIS2 ou un incident révèle ses limites : le DSI gère déjà l’exploitation informatique à temps plein, et personne ne pilote réellement le risque cyber de façon indépendante. C’est précisément là qu’interviennent le RSSI externalisé et le DSI, dans une répartition des rôles que beaucoup de dirigeants ont encore du mal à cerner.
RSSI externalisé et DSI ne font pas le même métier, ne répondent pas aux mêmes objectifs, et ne devraient jamais être fusionnés dans une seule fonction, même quand l’effectif de l’entreprise donnerait envie de simplifier l’organigramme. Une mission de RSSI externalisé vise justement à installer, aux côtés de la DSI, un regard indépendant sur le risque, pas à dupliquer son travail. Cet article détaille ce que fait chacun des deux rôles, pourquoi les confondre crée un angle mort dangereux, et comment structurer concrètement leur collaboration.
Deux objectifs différents par nature
Le DSI a pour mission de faire fonctionner le système d’information au service de l’activité de l’entreprise. Il arbitre les investissements techniques, pilote les projets d’infrastructure, garantit la disponibilité des outils métier. Sa réussite se mesure à la continuité de service et à la maîtrise des coûts d’exploitation.
Le RSSI, interne ou externalisé, a une mission différente par nature : il évalue et réduit le risque cyber de l’entreprise, indépendamment de qui a construit ou exploite le système. Sa réussite se mesure à la résistance de l’organisation face à une attaque, à sa conformité réglementaire, à sa capacité à réagir vite en cas d’incident. Ces deux objectifs se recoupent souvent, mais un DSI pressé par des impératifs de disponibilité n’a structurellement pas le même prisme de décision qu’un RSSI dont le mandat consiste justement à challenger ces arbitrages.
Un DSI qui repousse une mise à jour critique pour ne pas perturber une période de forte activité commerciale prend une décision parfaitement rationnelle de son point de vue métier. Un RSSI, lui, doit pouvoir chiffrer le risque que cette vulnérabilité fait courir et proposer une mesure compensatoire. Sans cette seconde voix, l’arbitrage se fait à sens unique, et c’est presque toujours la disponibilité qui l’emporte sur la sécurité.
Ce que fait le DSI en matière de sécurité
Le DSI reste un acteur central de la sécurité, mais sur un périmètre opérationnel et technique : il déploie les correctifs, administre les pare-feux et les solutions de protection des postes, gère les sauvegardes, applique les politiques d’accès, et choisit les prestataires techniques. Il exécute, au quotidien, une grande partie des mesures qui protègent l’entreprise.
Ce rôle d’exécution est indispensable, mais il souffre d’une limite structurelle : le DSI est juge et partie dès qu’il s’agit d’évaluer la sécurité de sa propre infrastructure. Il est rarement en position de dire à sa direction que le système qu’il a lui-même déployé présente des failles significatives, ni de consacrer le temps nécessaire à une analyse de risque formelle ou un plan de réponse à incident testé, alors que son emploi du temps est déjà saturé par le maintien en conditions opérationnelles du SI.
Ce que fait un RSSI externalisé
Le RSSI externalisé intervient sur un registre différent : la gouvernance du risque, indépendante de l’exploitation technique quotidienne. Sa mission couvre plusieurs volets qui se recoupent rarement avec ceux du DSI :
- il pilote l’analyse de risque de l’entreprise et hiérarchise les priorités selon l’exposition réelle du métier ;
- il définit et fait vivre la politique de sécurité (gestion des accès, classification des données, charte informatique) ;
- il commandite et interprète les audits et pentests, en toute indépendance vis-à-vis de l’équipe qui a construit l’infrastructure ;
- il pilote la conformité réglementaire, notamment NIS2, et les exigences des assureurs cyber ;
- il coordonne la réponse à incident au niveau décisionnel et rend compte à la direction générale avec des indicateurs compréhensibles par des non-techniciens.
D’après la fiche métier officielle du RSSI, ce périmètre couvre effectivement l’ensemble de la gouvernance sécurité, de l’évaluation des risques à la coordination de crise, bien au-delà de la seule administration technique. Un RSSI externalisé apporte, en plus, une indépendance structurelle que ni le DSI ni un RSSI interne rattaché hiérarchiquement à la DSI ne peuvent offrir de la même manière.
Pourquoi confondre les deux rôles crée un angle mort
La tentation de fusionner les deux fonctions dans une seule personne part d’une intention compréhensible : limiter les coûts et éviter la multiplication des interlocuteurs. Le problème est que cette fusion recrée exactement le conflit d’intérêt que la fonction RSSI est censée neutraliser : un DSI qui porte aussi la casquette RSSI doit auditer ses propres choix et challenger ses propres arbitrages budgétaires, ce qui suppose une objectivité difficile à tenir dans la durée.
À cela s’ajoute une contrainte plus prosaïque, celle du temps. La gouvernance sécurité, qui demande du temps dédié pour documenter, auditer et anticiper, finit systématiquement reléguée après les urgences opérationnelles. Résultat observé régulièrement chez SkillX lors des premiers audits de maturité : des politiques de sécurité obsolètes, des plans de réponse à incident jamais testés, des accès jamais revus depuis leur création, non par négligence, mais parce que personne n’avait explicitement le mandat de s’en occuper.
Cette confusion s’accompagne souvent d’un second travers : nommer un RSSI sans lui donner d’autorité réelle face à la DSI, ce qui transforme la fonction en simple rôle consultatif dès que les recommandations impliquent un coût ou un délai supplémentaire. La tentation d’économiser en fusionnant les deux rôles se heurte d’ailleurs vite à la réalité budgétaire : le coût d’un RSSI externalisé reste généralement sans commune mesure avec celui d’un incident non anticipé, et sa rentabilité dépend surtout de l’effectif et du chiffre d’affaires de l’entreprise, pas d’un principe d’économie a priori.
Comment structurer la collaboration dans une PME ou une ETI
Une répartition claire des rôles évite ces angles morts sans complexifier l’organisation. Le premier principe consiste à formaliser un point de rencontre régulier, généralement mensuel, entre le RSSI externalisé et le DSI : le RSSI présente les risques et les priorités, le DSI indique la faisabilité technique et le calendrier. Le second consiste à séparer clairement les rôles en cas d’incident : le RSSI prend la main sur la coordination décisionnelle (déclenchement du plan de réponse, communication, obligations légales), pendant que le DSI et ses équipes exécutent les actions techniques. Le troisième consiste à donner au RSSI un accès direct à la direction générale, sans passage obligé par la DSI, pour que les risques identifiés remontent sans filtre, y compris lorsqu’ils concernent des choix faits par la DSI elle-même.
Ce qu’il faut retenir
Une gouvernance cyber solide ne repose pas sur la compétence individuelle du DSI ou du RSSI, mais sur la clarté de la frontière entre les deux fonctions, et sur la volonté de la direction de la faire vivre, y compris quand elle dérange. Choisir un RSSI externalisé n’a de sens que si ce rôle reste distinct de celui du DSI, avec un mandat et un accès à la direction qui lui sont propres.
