"The Infrational Crisis" documented how word inflation — DevOps, Infrastructure as Code, XxxOps — emptied roles of their substance. "The Infrational Loop" documented how this title dissolution produces salary compression that pushes seniors out. "The State and the Invisible Body" documented how the absence of a recognised nomenclature deprives the infrastructure body of any institutional protection. These three pathologies share a common cause: nobody placed precise words on precise realities, and left the market to name at its convenience.

The RNCP already partially recognises infrastructure roles. RNCP37682 (Systems and Networks Senior Technician, level 5) and RNCP35594 (Systems, Networks and Databases Administrator) exist and are registered. The problem is twofold: these certifications systematically fuse systems and networks into a single title — erasing the functional distinction between the two domains — and they do not cover higher levels (engineer, lead, architect) with the same precision. This corpus's proposal completes the RNCP by offering a coherent taxonomy across the full pyramid.

Scope: everything touching operating systems, physical and virtual servers, low-level application services, storage, virtualisation, backup and restoration. It is the layer that transforms metal into usable service.

What SysOps is not: SysOps is not application development. A SysOps engineer may write automation scripts — but does not develop business applications. The boundary is the service layer: below it is SysOps. Above it is the developer.

Physical anchor: a SysOps engineer has touched a physical server. They know what RAID, a storage bay, and a hypervisor are. They can diagnose a hardware fault before opening a console.

Scope: everything touching networks — cabling, switching, routing, firewalls, VPN, WiFi, WAN, BGP, MPLS, DNS, DHCP, network monitoring. It is the layer that connects systems to each other and to the outside world.

What NetOps is not: NetOps is not security in the broad sense — SecOps is a distinct specialisation that builds on NetOps but is not a sub-category of it. A NetOps engineer secures the network. They are not the CISO.

Physical anchor: a NetOps engineer has cabled a switch. They can read a rack diagram, trace a backbone cable, diagnose packet loss on copper before blaming software.

Scope: the cross-domain layer that operates infrastructure as a whole — SREs, infrastructure architects, senior operations engineers who master both domains and operate at a level of responsibility over overall system availability.

What OpInfra is not: OpInfra is not DevOps. An OpInfra profile may automate, may write infrastructure code — but their centre of gravity is operational reliability, not feature delivery.

Physical anchor: an OpInfra engineer has documented mastery of the physical layer in at least one domain (SysOps or NetOps) before accessing engineer level.

A profile may exercise several nomenclature functions simultaneously. A Systems Administrator in a small town hall may also manage the local network, provide first-level support, and administer workstations. This is real and legitimate. But their title remains "Systems Administrator" — not "IT Manager", not "Digital Project Coordinator", not "Infrastructure Lead". These vague titles have no content in the nomenclature and open the door to dilution.

Functions exercised outside the primary title are documented in the job description as "complementary functions exercised according to organisational needs" — not as an additional title.

Small town hall (5,000 inhabitants): 1 profile, Systems Administrator (SysOps, level 3). Complementary functions exercised: local network management, user support, workstation administration. Not called "IT Manager" — called Systems Administrator with extended responsibilities.

SME (50 employees): 1 Systems Administrator + 1 Support Technician. The first manages infrastructure and networking. The second manages user support and workstations. Two people, two titles, no confusion.

Mid-size company (500 employees): 1 SRE Engineer (OpInfra) + 2 Systems Administrators + 1 Network Administrator + 2 Support Technicians. Specialisation becomes possible and necessary. Domain boundaries are respected.

Large IT department (5,000+ employees): full pyramid by domain. Leads and Architects emerge. OpInfra transversality is embodied by a dedicated SRE team.

— Calling a profile "DevOps engineer" without documented physical layer competence
— Calling a profile "cloud architect" without having designed network or systems architecture
— Creating composite titles not defined in the nomenclature ("Infrastructure & Cloud Expert", "Ops Lead", "Tech Lead DevSecOps")
— Using a higher-level title to save on recruiting a properly-levelled profile

"DevOps engineer" does not exist in this nomenclature. Not because the DevOps philosophy is rejected — collaboration between development and operations is a real value. But because "DevOps" is not a role: it is a work culture, an approach, a philosophy. One does not name a role after a philosophy. One names a role after what the person concretely does — the systems they administer, the networks they configure, the infrastructure they operate. A "DevOps engineer" who administers Linux servers is a Systems Engineer (SysOps) working in a DevOps culture. The title says what they do. The culture is documented in team practices, not in the title.

SecOps is a specialisation — a Systems or Network Engineer with a security specialisation. They were called "Systems Engineer, security specialisation" or "Network Engineer, security specialisation". FinOps is a cloud financial governance practice — not an infrastructure role. MLOps is a hybrid developer/operations profile oriented toward machine learning — belonging more to the developer category than the infrastructure category. These specialisations exist. They do not justify creating a new category in the infrastructure nomenclature.

"Cloud Engineer" or "Cloud Architect" are marketing titles that describe an execution context (the cloud), not an operational competence. A Systems Engineer who works primarily on AWS is a Systems Engineer — not a "Cloud Engineer". The precision of the competence domain (Linux, Windows, virtualisation, containerisation) and hierarchical level (engineer, lead, architect) says everything needed about the profile. The word "Cloud" in the title says where they work — not what they know how to do.

Any IT department, digital services firm, local authority or company can adopt this nomenclature tomorrow, without waiting for legislation or collective agreements. It replaces its vague titles with nomenclature titles in its job descriptions, org charts and job postings. This unilateral decision has three immediate effects: it clarifies responsibilities internally, it improves recruitment precision, and it contributes to building the critical mass that will make the nomenclature visible on the market.

The nomenclature can be proposed to digital sector social partners as a basis for revising classification grids. Syntec, which covers the majority of IT services firms, has a classification grid that does not clearly distinguish SysOps / NetOps domains. A revision integrating the nomenclature would produce salary scales by level and domain — mechanically reducing the compression documented in "The Infrational Loop". Simultaneously, the titles can be proposed to France Compétences for RNCP registration — complementing existing certifications, not replacing them.

BTS SIO, DUT Networks & Telecoms and Bac+3/4 infrastructure training programmes can align their career outcome labels with the nomenclature. Instead of promising a "systems and networks technician or DevOps engineer position", training promises a "Systems Technician position (SysOps, level 2)" with a documented path toward "Systems Administrator (level 3) then Systems Engineer (level 4)". Pathway readability is the condition of filière attractiveness — particularly for female audiences documented in "The Invisible Amputation".