Comment construire une organisation DSI cible pour porter le schéma directeur

C’est une des premières questions qu’on se pose en prenant la tête d’une DSI, ou en la réorganisant : à quoi doit ressembler l’organigramme ? La tentation est de copier celui d’une DSI qu’on admire, ou celui de son ancien poste. C’est presque toujours une erreur. Une organisation qui fonctionne ailleurs échoue souvent chez vous, parce qu’elle a été taillée pour une autre taille, un autre secteur, d’autres contraintes. Organiser une DSI, ce n’est pas appliquer un modèle : c’est traduire un contexte en structure.

Il n’existe pas d’organigramme type

La bonne organisation d’une DSI dépend de quelques variables déterminantes, et la première est la taille. On ne structure pas de la même façon une équipe de dix personnes et une direction de deux cents. Dans la première, une personne porte plusieurs fonctions ; dans la seconde, chaque fonction devient une équipe.

Viennent ensuite le modèle (une DSI centralisée ne se découpe pas comme un groupe multi-entités avec des IT locales), le secteur (les enjeux d’une banque ne sont pas ceux d’une industrie), et la réglementation (une contrainte comme NIS2 ou DORA fait apparaître des rôles qui n’existeraient pas ailleurs). Copier un organigramme, c’est importer les réponses de quelqu’un d’autre à des questions qui ne sont pas les vôtres.

Se donner un langage commun

Avant de dessiner des cases, il faut nommer ce qu’on y met. Et là, inutile d’inventer : la profession dispose de référentiels de métiers reconnus. Le CIGREF, notamment, décrit les familles de profils d’une DSI — production, études, sécurité, données, pilotage, relation métier… S’appuyer sur ce langage commun donne deux avantages : vos choix deviennent défendables (vous parlez la langue des DRH et des pairs), et vous évitez d’oublier des pans entiers d’activité. C’est le même principe que pour l’audit de maturité : on s’ancre sur des référentiels reconnus plutôt que sur des avis personnels.

Dimensionner : combien d’équipes ?

Une fois le vocabulaire posé, la vraie question est celle du découpage. Combien de départements, de pôles, d’équipes ? La réponse suit la taille, par paliers.

Dans une petite DSI, on ne crée pas d’équipes : on regroupe. Production et applications ensemble, projets et urbanisation ensemble, et le reste — sécurité, données, pilotage — porté directement par le DSI. Dans une DSI moyenne, ces regroupements se scindent : l’infrastructure et le support d’un côté, les applications et la donnée de l’autre, les projets et la sécurité qui gagnent leur autonomie. Dans une grande DSI, chaque grande fonction devient une entité à part entière, avec son responsable et ses équipes. Le principe à retenir n’est pas un chiffre magique, c’est une logique : on ne crée une entité que lorsque le volume la rend nécessaire et pilotable. Créer trop tôt un département pour trois personnes fabrique de la coordination inutile ; le créer trop tard sature ceux qui portent la casquette.

Les rôles qu’on ne voit pas, mais qu’il faut tenir

Un organigramme montre les équipes visibles — développement, exploitation, support. Il masque les rôles transverses qui, eux, doivent toujours être tenus : gouvernance et pilotage, sécurité, protection des données, gestion des risques, relation avec les métiers, pilotage budgétaire. Dans une grande DSI, ce sont des postes dédiés. Dans une petite, ce sont des casquettes : le DSI est aussi son propre RSSI, son propre contrôleur de gestion, son propre chef de projet.

Le danger n’est pas de cumuler les casquettes — c’est normal quand on est peu nombreux. Le danger, c’est de ne pas savoir qui les porte. Une responsabilité sans titulaire identifié est une responsabilité qui tombe. Cartographier ces rôles, même quand ils sont mutualisés, c’est s’assurer que rien d’essentiel n’est orphelin.

Le management n’est pas un département

Une erreur récurrente : faire du management une case de l’organigramme. Le management opérationnel n’est pas une fonction à côté des autres, c’est une couche qui les traverse toutes. Il se répartit sur chaque entité, il ne s’isole pas dans un pôle « encadrement ». En faire un département, c’est créer une strate qui éloigne les décisions du terrain — l’inverse de ce qu’on cherche.

L’organisation fait partie du schéma directeur

On pense souvent l’organisation à part de la stratégie SI. C’est une erreur de séquence. Un schéma directeur aligne des initiatives, des jalons, des budgets — mais sans les bonnes personnes aux bons endroits, aucun plan d’action ne se déroule. Une trajectoire ambitieuse portée par une organisation sous-dimensionnée ou mal répartie reste sur le papier.

C’est pourquoi l’organisation cible n’est pas un chantier annexe : c’est ce qui rend le schéma directeur exécutable. Objectiver l’existant — qui fait quoi, quels rôles sont tenus, où sont les manques — puis dessiner l’organisation qui permet de dérouler le plan, c’est boucler la boucle entre le diagnostic et l’action. C’est précisément ce que nous relions dans Audit DSI : la maturité, le schéma directeur, et l’organisation qui le porte. Pour la logique d’évaluation, voir comment j’évalue le niveau d’une DSI.

Organiser une DSI, ce n’est pas recopier un modèle : c’est partir de sa taille, de son contexte et de ses contraintes, se donner un langage commun pour nommer les métiers, dimensionner sans excès ni manque, et s’assurer qu’aucun rôle essentiel n’est orphelin. Et surtout, ne pas traiter l’organisation comme une question RH isolée : c’est le socle humain sans lequel le meilleur des schémas directeurs reste une intention. La structure n’est pas le décor de la stratégie — elle en est la condition. C’est d’ailleurs souvent l’un des premiers constats qu’on pose en prise de poste.