100%
GRIMOIRE
GrimoireCorpus DindonVolumes de SynthèseLe Socle du Fer
FRENAR
RATIO
ÉTUDE STRUCTURELLE · OPÉRATION DINDON · JUIN 2026
◆◆◆
LE TICKET
ET LE TALENT
Nomenclature des corps infrastructure
SysOps · NetOps · OpInfra
◆ CONTEXTE DE L'ÉTUDE

Cette étude propose une nomenclature structurée des métiers de l'infrastructure numérique en trois catégories — SysOps, NetOps, OpInfra — et six niveaux hiérarchiques. Elle répond directement à "La Crise Infrationnelle" en posant des mots précis sur des réalités que le vocabulaire DevOps a progressivement effacées. La règle fondatrice : ne jamais aller au-delà de ce nommage, sous peine de perdre le sens et de provoquer la dissolution que le corpus a documentée.

◆◆◆
Amine RAITI — Architecte Infrastructure & SRE
Formateur depuis 2006 · De l'électricité à Kubernetes · Tous publics
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine · Opération Dindon
RATIO
1
SECTION 1 · POURQUOI UNE NOMENCLATURE — ET POURQUOI MAINTENANT
LES MOTS AVANT LES STRUCTURES

Une nomenclature des métiers n'est pas un exercice bureaucratique. C'est un acte politique — au sens étymologique du terme : un acte qui concerne la cité, la collectivité, l'organisation du vivre ensemble professionnel. Nommer correctement les métiers de l'infrastructure, c'est poser les conditions de leur reconnaissance, de leur rémunération, de leur protection et de leur transmission.

◆ CE QUE L'ABSENCE DE NOMENCLATURE PRODUIT — LE DIAGNOSTIC DU CORPUS

"La Crise Infrationnelle" a documenté comment l'inflation des mots — DevOps, Infrastructure as Code, XxxOps — a vidé les métiers de leur substance. "La Boucle Infrationnelle" a documenté comment cette dissolution des titres produit une compression salariale qui pousse les seniors à partir. "L'État et le Corps Invisible" a documenté comment l'absence de nomenclature reconnue prive le corps infrastructure de toute protection institutionnelle. Ces trois pathologies ont une cause commune : personne n'a posé de mots précis sur des réalités précises, et laissé le marché nommer à sa convenance.

◆ CE QUE LE RNCP FAIT — ET CE QU'IL NE FAIT PAS

Le RNCP reconnaît déjà partiellement les métiers de l'infrastructure. Le RNCP37682 (Technicien Supérieur Systèmes et Réseaux, niveau 5) et le RNCP35594 (Administrateur Systèmes, Réseaux et Bases de Données) existent et sont inscrits. Le problème est double : ces certifications fusionnent systèmes et réseaux dans un seul titre — effaçant la distinction fonctionnelle entre les deux domaines — et elles ne couvrent pas les niveaux supérieurs (ingénieur, lead, architecte) avec la même précision. La proposition de ce corpus complète le RNCP en proposant une taxonomie cohérente sur l'ensemble de la pyramide.

◆ NASSIHA — LA NOMENCLATURE N'EST PAS UNE FIN EN SOI

Une nomenclature sans force de loi est un catalogue. Elle n'a de valeur que si elle est adoptée dans les conventions collectives, les référentiels de marchés publics, les fiches de poste des DSI et les programmes de formation. Cette étude pose les mots. L'étude "L'État et le Corps Invisible" a posé les mécanismes pour leur donner force. Les deux sont nécessaires.

RATIO
2
SECTION 2 · LES TROIS CATÉGORIES
SYSOPS · NETOPS · OPINFRA

La nomenclature s'organise en trois catégories fonctionnelles. Elles ne sont pas des silos — elles sont des domaines de compétence primaires qui définissent où l'ingénieur a son centre de gravité. Un profil peut opérer dans deux catégories à la fois — dans une petite structure, c'est souvent nécessaire. Mais son titre reste ancré dans sa catégorie principale.

◆ SYSOPS — LES OPÉRATIONS SYSTÈMES

Périmètre : tout ce qui touche aux systèmes d'exploitation, aux serveurs physiques et virtuels, aux services applicatifs bas niveau, au stockage, à la virtualisation, à la sauvegarde et à la restauration. C'est la couche qui transforme du métal en service utilisable.

Ce que SysOps n'est pas : SysOps n'est pas le développement applicatif. Un SysOps peut écrire des scripts d'automatisation — mais il ne développe pas des applications métier. La frontière est la couche de service : en dessous, c'est SysOps. Au-dessus, c'est le développeur.

Ancrage physique : un SysOps a touché un serveur physique. Il sait ce qu'est un RAID, une baie de stockage, un hyperviseur. Il sait diagnostiquer une panne matérielle avant d'ouvrir une console.

◆ NETOPS — LES OPÉRATIONS RÉSEAUX

Périmètre : tout ce qui touche aux réseaux — câblage, commutation, routage, pare-feu, VPN, WiFi, WAN, BGP, MPLS, DNS, DHCP, supervision réseau. C'est la couche qui connecte les systèmes entre eux et avec l'extérieur.

Ce que NetOps n'est pas : NetOps n'est pas la sécurité au sens large — SecOps est une spécialisation distincte qui s'appuie sur NetOps mais n'en est pas une sous-catégorie. Un NetOps sécurise le réseau. Il n'est pas RSSI.

Ancrage physique : un NetOps a câblé un switch. Il sait lire un schéma de baie, tracer un câble de backbone, diagnostiquer une perte de paquets sur du cuivre avant d'accuser le logiciel.

◆ OPINFRA — LES OPÉRATIONS INFRASTRUCTURE TRANSVERSALES

Périmètre : la couche transversale qui opère l'infrastructure dans son ensemble — SRE, architectes infrastructure, ingénieurs d'exploitation senior qui maîtrisent les deux domaines et opèrent à un niveau de responsabilité sur la disponibilité globale des systèmes.

Ce qu'OpInfra n'est pas : OpInfra n'est pas DevOps. Un profil OpInfra peut automatiser, peut écrire du code d'infrastructure — mais son centre de gravité est la fiabilité opérationnelle, pas la livraison de fonctionnalités.

Ancrage physique : un OpInfra a une maîtrise documentée de la couche physique dans au moins un des deux domaines (SysOps ou NetOps) avant d'accéder au niveau ingénieur.

RATIO
3
SECTION 3 · LES SIX NIVEAUX HIÉRARCHIQUES
DE LA PROXIMITÉ À L'ARCHITECTURE — LA PYRAMIDE COMPLÈTE
◆ LA PYRAMIDE — TABLEAU COMPLET

NIVEAU 1 — SUPPORT / PROXIMITÉ
Technicien Support · Technicien Proximité
Premier contact utilisateur. Diagnostic de premier niveau. Escalade vers le niveau 2. Ne touche pas aux configurations serveur ou réseau en production sans supervision. Correspond au RNCP37682 bloc 1 partiel.

NIVEAU 2 — TECHNICIEN DOMAINE
Technicien Systèmes (SysOps) · Technicien Réseaux (NetOps)
Exploitation quotidienne. Maintien en condition opérationnelle. Intervient sur les systèmes ou réseaux sous consignes et procédures. Contribue à la documentation. Correspond au RNCP37682 complet (niveau 5 — Bac+2).

NIVEAU 3 — ADMINISTRATEUR DOMAINE
Administrateur Systèmes (SysOps) · Administrateur Réseaux (NetOps)
Administration autonome. Conception de configurations. Responsabilité de sous-ensembles de l'infrastructure. Gestion des incidents de niveau 2. Correspond au RNCP35594 (niveau 6 — Bac+3/4).

NIVEAU 4 — INGÉNIEUR DOMAINE
Ingénieur Systèmes (SysOps) · Ingénieur Réseaux (NetOps) · Ingénieur SRE (OpInfra)
Conception d'architectures de niveau intermédiaire. Responsabilité de la fiabilité d'un périmètre défini. Supervision des niveaux inférieurs. Rédaction de procédures et runbooks. Niveau 6 à 7 RNCP (Bac+3 à Bac+5).

NIVEAU 5 — LEAD / PRINCIPAL
Lead Systèmes · Lead Réseaux · Principal SRE
Référent technique senior. Conception d'architectures complexes. Mentorat des équipes. Décisions techniques structurantes. Pas nécessairement manager hiérarchique — expertise technique avant tout.

NIVEAU 6 — ARCHITECTE
Architecte Systèmes · Architecte Réseaux · Architecte Infrastructure (OpInfra)
Vision transversale. Conception de l'infrastructure dans son ensemble. Gouvernance technique. Interlocuteur de la DSI et de la direction. Responsabilité de la cohérence et de l'évolution à moyen terme.

◆ NASSIHA — LE LEAD N'EST PAS LE MANAGER

Le niveau Lead / Principal est une voie d'évolution technique — pas managériale. Un Principal SRE qui ne veut pas gérer des équipes ne doit pas être contraint de devenir manager pour accéder au niveau de rémunération correspondant à sa compétence. La dissociation entre progression technique et progression managériale est une condition de rétention des meilleurs profils techniques.

RATIO
4
SECTION 4 · LA RÈGLE DES MULTI-CASQUETTES
UN PROFIL PEUT PORTER PLUSIEURS FONCTIONS — PAS PLUSIEURS NOMS

La règle des multi-casquettes est la réponse pragmatique à la réalité des petites et moyennes organisations. Elle ne contredit pas la nomenclature — elle l'applique intelligemment dans des contextes où les ressources ne permettent pas une spécialisation stricte par domaine.

◆ LE PRINCIPE — FONCTIONS MULTIPLES, TITRE UNIQUE

Un profil peut exercer plusieurs fonctions de la nomenclature simultanément. Un Administrateur Systèmes dans une petite mairie peut aussi gérer le réseau local, assurer le support de premier niveau, et administrer les postes de travail. C'est réel et légitime. Mais son titre reste "Administrateur Systèmes" — pas "Responsable Informatique", pas "Chef de Projet Digital", pas "Coordinateur Infrastructure Numérique". Ces titres flous n'ont pas de contenu dans la nomenclature et ouvrent la porte à la dilution.

Les fonctions exercées en dehors du titre principal sont documentées dans la fiche de poste comme "fonctions complémentaires exercées selon les besoins de l'organisation" — pas comme un titre supplémentaire.

◆ EXEMPLES CONCRETS PAR TAILLE D'ORGANISATION

Petite mairie (5 000 habitants) : 1 profil, Administrateur Systèmes (SysOps, niveau 3). Fonctions complémentaires exercées : gestion du réseau local, support utilisateurs, administration des postes. Il ne s'appelle pas "Responsable Informatique" — il s'appelle Administrateur Systèmes avec des responsabilités élargies.

PME (50 salariés) : 1 Administrateur Systèmes + 1 Technicien Support. Le premier gère l'infrastructure et le réseau. Le second gère le support utilisateur et les postes. Deux personnes, deux titres, pas de confusion.

ETI (500 salariés) : 1 Ingénieur SRE (OpInfra) + 2 Administrateurs Systèmes + 1 Administrateur Réseaux + 2 Techniciens Support. La spécialisation devient possible et nécessaire. Les frontières de domaine sont respectées.

Grande DSI (5 000+ salariés) : pyramide complète par domaine. Les Lead et Architectes émergent. La transversalité OpInfra est incarnée par une équipe SRE dédiée.

◆ CE QUE LA RÈGLE INTERDIT EXPLICITEMENT

— Appeler "ingénieur DevOps" un profil qui n'a pas de compétence documentée en couche physique
— Appeler "architecte cloud" un profil qui n'a jamais conçu d'architecture réseau ou système
— Créer des titres composites non définis dans la nomenclature ("Expert Infrastructure et Cloud", "Responsable Ops", "Tech Lead DevSecOps")
— Utiliser un titre de niveau supérieur pour économiser un recrutement de niveau adapté

RATIO
5
SECTION 5 · LES FRONTIÈRES QUI PROTÈGENT LE SENS
CE QUE LA NOMENCLATURE NE NOMME PAS — ET POURQUOI

Une nomenclature qui dit ce qu'elle nomme doit aussi dire ce qu'elle ne nomme pas. Les frontières sont aussi importantes que les définitions — elles protègent le sens contre la dilution progressive.

◆ DEVOPS N'EST PAS UN TITRE DANS CETTE NOMENCLATURE

"Ingénieur DevOps" n'existe pas dans cette nomenclature. Ce n'est pas parce que la philosophie DevOps est rejetée — la collaboration entre développement et opérations est une valeur réelle. C'est parce que "DevOps" n'est pas un métier : c'est une culture de travail, une approche, une philosophie. On ne nomme pas un métier d'après une philosophie. On nomme un métier d'après ce que la personne fait concrètement — les systèmes qu'elle administre, les réseaux qu'elle configure, l'infrastructure qu'elle opère. Un "ingénieur DevOps" qui administre des serveurs Linux est un Ingénieur Systèmes (SysOps) qui travaille dans une culture DevOps. Le titre dit ce qu'il fait. La culture est documentée dans les pratiques de l'équipe, pas dans le titre.

◆ SECOPS, FINOPS, MLOPS — NE SONT PAS DES CATÉGORIES

SecOps est une spécialisation — un Ingénieur Systèmes ou un Ingénieur Réseaux avec une spécialisation en sécurité. Il s'appelait "Ingénieur Systèmes, spécialisation sécurité" ou "Ingénieur Réseaux, spécialisation sécurité". FinOps est une pratique de gouvernance financière du cloud — pas un métier infrastructure. MLOps est un profil hybride développeur/opérations orienté machine learning — qui appartient davantage à la catégorie développeur qu'à la catégorie infrastructure. Ces spécialisations existent. Elles ne justifient pas de créer une nouvelle catégorie dans la nomenclature infrastructure.

◆ CLOUD ENGINEER N'EST PAS UN TITRE DE CETTE NOMENCLATURE

"Cloud Engineer" ou "Cloud Architect" sont des titres marketing qui décrivent un contexte d'exécution (le cloud), pas une compétence opérationnelle. Un Ingénieur Systèmes qui travaille principalement sur AWS est un Ingénieur Systèmes — pas un "Cloud Engineer". La précision du domaine de compétence (Linux, Windows, virtualisation, conteneurisation) et du niveau hiérarchique (ingénieur, lead, architecte) dit tout ce qu'il faut savoir sur le profil. Le mot "Cloud" dans le titre dit où il travaille — pas ce qu'il sait faire.

◆ LA RÈGLE FONDATRICE — NE PAS DÉPASSER CE NOMMAGE

Toute organisation qui adopte cette nomenclature s'engage à ne pas créer de titres au-delà de ceux définis. Pas de "Super Ingénieur Infrastructure Cloud DevOps Senior". Pas de "Lead Tech SRE Platform". Les mots existants dans la nomenclature suffisent à décrire n'importe quel profil infrastructure réel. Si un titre ne peut pas s'exprimer dans les mots de la nomenclature, c'est soit que le profil est mal défini, soit que le titre est inventé pour masquer un problème de classification.

RATIO
6
SECTION 6 · MISE EN ŒUVRE — COMMENT ADOPTER LA NOMENCLATURE
DU MOT À L'ACTE — TROIS VECTEURS D'ADOPTION

Une nomenclature n'a de valeur que si elle est adoptée. L'adoption passe par trois vecteurs distincts qui se renforcent mutuellement. Chacun peut agir indépendamment — l'ensemble crée une masse critique.

◆ VECTEUR 1 — LES ORGANISATIONS ELLES-MÊMES

Toute DSI, ESN, collectivité ou entreprise peut adopter cette nomenclature demain, sans attendre une loi ou une convention collective. Elle remplace ses titres flous par les titres de la nomenclature dans ses fiches de poste, ses organigrammes et ses offres d'emploi. Cette décision unilatérale a trois effets immédiats : elle clarifie les responsabilités en interne, elle améliore la précision des recrutements, et elle contribue à construire la masse critique qui rendra la nomenclature visible sur le marché.

◆ VECTEUR 2 — LES CONVENTIONS COLLECTIVES ET LE RNCP

La nomenclature peut être proposée aux partenaires sociaux du secteur numérique comme base de révision des grilles de classification. La Syntec, qui couvre la majorité des ESN, a une grille de classification qui ne distingue pas clairement les domaines SysOps / NetOps. Une révision intégrant la nomenclature produirait des grilles salariales par niveau et par domaine — réduisant mécaniquement la compression documentée dans "La Boucle Infrationnelle". Simultanément, les titres peuvent être proposés à France Compétences pour inscription au RNCP — en complément des certifications existantes, pas en remplacement.

◆ VECTEUR 3 — LES ORGANISMES DE FORMATION

Les BTS SIO, DUT Réseaux & Télécoms et formations Bac+3/4 infrastructure peuvent aligner leurs intitulés de débouchés sur la nomenclature. Au lieu de promettre un "poste de technicien systèmes et réseaux ou ingénieur DevOps", la formation promet un "poste de Technicien Systèmes (SysOps, niveau 2)" avec une trajectoire documentée vers "Administrateur Systèmes (niveau 3) puis Ingénieur Systèmes (niveau 4)". La lisibilité du parcours est la condition de l'attractivité de la filière — particulièrement pour les publics féminins documentés dans "L'Amputation Invisible".

◆◆◆

Les mots sont les actes les moins coûteux et les plus structurants. Nommer correctement un métier, c'est lui redonner sa valeur. Cette nomenclature est un acte de résistance contre la dissolution — et un acte de construction pour ceux qui viennent après.

◆◆◆
NEMO SUPRA LEGEM EST