URL:     https://linuxfr.org/users/dafyd/journaux/du-ridicule-de-l-it-en-grande-entreprise
Title:   Du ridicule de l'IT en grande entreprise
Authors: Dafyd
Date:    2026-06-09T23:41:53+02:00
License: CC By-SA
Tags:    râlage, dénonce, merdification, bureaucratie, capitalisme, entreprise et fatigue
Score:   49


Cher journal,

Aujourd'hui je t'écris pour partager mon expérience d'architecte IT dans une grande entreprise française.

# Contexte

Je travaille dans une grosse boite avec beaucoup de coeurs de métier différents et donc d'outils informatiques différents. L'informatique de la boutique est gigantesque, avec des portions sur des clouds publics, d'autres sur des clouds privés, d'autres complètement on prem accessibles d'ailleurs, et enfin d'autres complètement on prem et totalement isolés (air gap).

Nous gérons donc un grand nombre de SI différents, de tailles différents, pour des usages différents.

# Mon métier

Mon travail, c'est de prendre un problème, ou un besoin métier, ou une évolution réglementaire, et d'y apporter une solution IT répondant au besoin, à la réglementation, avec des coûts et délais maitrisés (à peu près).

Avec si possible une recherche de cohérence technologique entre les différents environnements afin que les pauvres sysadmins et admins réseau ne se retrouvent pas avec 40 technos différents à maitriser pour faire leur job.

Ah oui, et documenter le tout. Rétro-documenter parfois, le plus amusant (lol).

Evidemment dans ma DSI je ne suis pas tout seul, avec les collègues on se parle et on tente d'avancer dans la même direction.

# L'Architecte d'Entreprise

Disclaimer : cette section ne sera pas objective.

Dans toute grande boite comme ça, il y a (à Paris si possible, dans un grand building vitré, au 24ème étage), des gens "en central" qui sont Architectes  d'Entreprise. Leur métier consiste à réfléchir à long terme, et à orienter les grandes tendances et patterns d'architecture de l'IT de la boutique dans son ensemble. C'est donc un travail nécessitant un haut niveau d'abstraction et une fine connaissance du marché et des technos. Qu'est-ce qui est intéressant  mais qui dans 2 ans n'existera plus ? Comment faire en sorte que les jeunes dev ne fuient pas au bout de 2 semaines devant l'IT de dev ? Etc... C'est un travail important.

Ce genre de personne est donc très souvent assez loin des problématiques de  terrain et produit majoritairement des slides et des réunions Teams.

# L'architecte technique

L'architecte technique est une personne experte dans un domaine IT ou une techno donnée. Dans les grosses boites, on les trouve souvent en équipe : les experts stockage, les experts virtu, Windows, annuaire, etc... Ces gens  produisent des briques de base IT parfaitement maitrisées que les archis solution utilisent pour concevoir... ben des solutions IT quoi.

# La théorie

En théorie, les architectes d'entreprise fixent donc les grandes cibles des  évolutions du SI. Les architectes solution (moi) conçoivent une solution IT permettant d'atteindre cette cible, avec les briques de bases d'IT standard de la boutique. Ensuite, les admins, assistés des experts, installent tout ce  bazar, et en assurent ensuite l'exploitation. Il arrive parfois que les  équipes de "build" et de "run" soient séparées, parfois avec un niveau de  sous-traitance en plus.

Dans un monde merveilleux, tout va bien.

# En pratique

Voici comment ça se passe en pratique :

1) Un grand chef se réveille un matin et dit : nous devons mover vers le cloud car tout le monde le fait.

2) le CTO et ses architectes d'entreprise font plein de slides jolies.

3) La sécurité passe par la et explique que non, tout va pas aller chez les  GAFAM, et que faut ségréguer, hybrider, on premiser, segmenter, etc...

4) On prend un cabinet externe pour concevoir une solution déclinable dans  tous les cas : 1 gros building block, qu'on sait instancier chez GAFAM, chez  nous, autant de fois qu'on a de SI. Evidemment, ça accouche d'une usine à gaz monstrueuse avec tous les trucs hypes du moment, très cher tant qu'à faire.

5) Le corp déploie la version centrale de la boutique. Des équipes d'experts  sont créés sur le sujet, une équipe maitrise bien. Ca va.

6) Le corp, pour rentabiliser son investissement humain, demande aux sous-DSI (nous), de déployer la même chose dans ses SI.

7) Le temps de trouver les sous, d'adapter l'archi aux contraintes locales, d'acheter le matériel, 2 ans passent.

8) Entre-temps, le corp a changé de cible, a pondu une autre usine à gaz,  démantelé les équipes pour les faire bosser sur la nouvelle solution vachement plus mieux.

9) Quand nous on commence à déployer Solution A, on a plus de support dessus car le corp est passé sur la B.

10) Retour étape 1.

# Bilan

Avant, on avait sur chaque SI 2 grosses solutions un peu old school mais qui marchent, et la super solution devait tout réunir sur une seule plateforme trop bien qui est la même dans toute la boutique.

Maintenant, on a 3 grosses solutions un peu old school. Et on a pas le temps de migrer les 2 premières sur la troisième car faut installer la quatrième.

# Résister

Je suis un fervent partisan des solutions simples. On est pas un cloud provider. On fournit pas 200 VM par jour. Pour de l’isolé du net, un bon trois tiers virtu/SAN/stockage, c’est très bien. C’est pas cher. C’est rock solid. Les admins maitrisent. Mais c’est pas moderne. Je suis pas moderne. Et je l’assume.