Une ontologie pour AI for IT

Pourquoi une ontologie pour AI for IT ?

Le vocabulaire du développement assisté par IA s'est emballé en deux ans. Développeur augmenté, copilote, agent autonome, vibe coding, compound engineering, orchestrateur, Product Engineer : chaque terme circule, chacun est compris différemment selon l'interlocuteur, et tous se chevauchent. Le résultat est familier — des conversations stratégiques où l'on croit s'entendre alors qu'on parle de réalités différentes, des offres commerciales qui se ressemblent toutes parce qu'elles utilisent les mêmes mots, des programmes de transformation qui échouent à se mesurer parce que leurs objectifs sont implicites.

Le terme développeur augmenté illustre bien le phénomène. Il est utile en positionnement : il s'inscrit dans la tradition d'Engelbart sur l'augmentation de l'intellect, il préserve la centralité humaine, et il est compris dans l'écosystème francophone. Mais comme pivot ontologique, il est trop générique. Il couvre l'autocomplétion Copilot et l'orchestration d'agents Claude Code dans le même mot. Il est binaire — augmenté ou pas — alors que le domaine est multidimensionnel. Surtout, il confond trois choses qui doivent rester distinctes : un paradigme (l'augmentation comme philosophie), un rôle (la personne qui exerce), et une pratique (la manière de coder).

Une ontologie n'est pas un jargon supplémentaire. C'est l'inverse : l'effort qu'on fait pour cesser d'en produire.

Une ontologie résout ce flou. Elle nomme précisément les concepts, en explicite les relations, et fournit un référentiel partagé qu'on peut requêter, croiser, faire évoluer. Pour SFEIR — et plus largement pour quiconque veut structurer une offre AI for IT — elle remplit trois fonctions concrètes :

• Clarifier les offres. Distinguer mécaniquement « Copilot enterprise enablement » d'une « Software Factory 10x agentique », plutôt que les laisser se confondre sous la même étiquette.
• Structurer la KB. Donner une colonne vertébrale aux articles, études de cas, retours d'expérience : chaque contenu se rattache à des rôles, pratiques et systèmes identifiés.
• Mesurer la transformation. Définir une trajectoire — d'une pratique vers une autre — avec des marqueurs observables, plutôt qu'un brouillard d'intentions.

Cet article présente une ontologie compacte mais complète, conçue pour être à la fois suffisamment formelle (sérialisable en OWL/Turtle, requêtable en SPARQL) et suffisamment lisible pour servir de référentiel éditorial. Elle peut être étendue, et elle est prévue pour l'être.

Trois séparations strictes : rôle, pratique, système

Le geste fondateur de l'ontologie consiste à séparer trois dimensions que le langage courant écrase. Une fois ces dimensions distinguées, tout le reste — la richesse, les nuances, la capacité à modéliser des cas singuliers — découle de leur recombinaison.

Le rôle : qui

Un rôle décrit la posture qu'un humain adopte dans un contexte donné. Développeur augmenté, Orchestrateur, Ingénieur agentique, Product Engineer, Vibe coder sont des rôles. Une même personne en tient plusieurs au cours d'une journée — le Product Engineer du matin devient orchestrateur l'après-midi quand il pilote un refactoring multi-fichiers via Claude Code. Le rôle n'est pas une identité figée, c'est une position relationnelle face au système IA et au produit livré.

La pratique : comment

Une pratique décrit une manière de travailler observable et caractérisable. Pair-programming IA, Compound engineering, Spec-driven development, Vibe coding, End-to-end product delivery sont des pratiques. Une pratique se définit par sa signature — sa position sur les sept axes orthogonaux que nous décrirons en section suivante. Deux pratiques différentes ont des signatures différentes ; deux pratiques qui ont la même signature sont en réalité la même pratique nommée différemment.

Le système IA : avec quoi

Un système IA est l'outillage qui active une pratique. GitHub Copilot, Claude Code, Cursor, Devin, RAISE, un modèle de fondation comme Claude ou GPT : ce sont des classes d'outils qui rendent telle ou telle pratique possible. Un même système peut activer plusieurs pratiques ; une même pratique peut s'appuyer sur plusieurs systèmes.

Pourquoi cette séparation — Si l'on confond les trois — comme le fait le terme « développeur augmenté » pris seul — on ne peut plus décrire un Product Engineer qui utilise tantôt Copilot en pair-programming, tantôt Claude Code en orchestration, tantôt RAISE pour piloter un agent autonome. On a un seul mot pour trois situations. Avec la séparation, le rôle reste constant (Product Engineer), la pratique change selon la tâche, le système change selon la pratique.

Les rôles n'utilisent jamais directement les systèmes IA dans l'ontologie. Le lien passe toujours par la pratique. Un rôle applique des pratiques, une pratique est activée par des systèmes IA. Cette transitivité est volontaire : elle empêche l'erreur de catégorie qui consisterait à dire « Product Engineer = utilisateur de Claude Code », ce qui figerait la définition du rôle dans l'outillage du moment.

Sept axes orthogonaux pour caractériser une pratique

Une pratique se définit par sa position sur sept axes orthogonaux. Orthogonaux signifie qu'aucun axe n'est dérivable des autres — ils mesurent des propriétés genuinement indépendantes. C'est ce qui rend l'ontologie discriminante : deux pratiques peuvent avoir le même niveau d'autonomie de l'IA mais différer par le locus de l'intention, ou la même granularité mais une phase SDLC différente.

1. Niveau d'autonomie de l'IA (L0 → L5)

Inspiré de l'échelle SAE pour la conduite autonome, cet axe gradue ce que le système IA fait tout seul, sans intervention humaine. L0 = manuel, L1 = autocomplétion ligne à ligne, L2 = génération sur demande, L3 = tâches entières déléguées, L4 = enchaînement multi-étapes supervisé, L5 = bout-en-bout sans supervision. C'est la dimension la plus visible mais aussi la plus trompeuse prise seule : un L4 mal piloté peut être moins productif qu'un L1 bien maîtrisé.

2. Mode de collaboration (Centaure / Cyborg)

Reprise du cadre d'Ethan Mollick. Le centaure sépare clairement les tâches : l'humain fait certaines choses, l'IA en fait d'autres, on bascule explicitement entre les deux. Le cyborg intègre l'IA en flux continu — l'humain et l'IA pensent ensemble, sans frontière nette. Le pair-programming Copilot est typiquement cyborg ; déléguer un module entier à Claude Code est typiquement centaure.

Note de vocabulaire SFEIR : cyborg et bionique sont employés comme synonymes. On peut parler indifféremment d'une organisation bionique ou d'une organisation cyborg, d'un projet bionique ou d'un projet cyborg — c'est le même objet vu sous deux angles. Bionique vient du registre médical et industriel (la prothèse au service de l'humain), cyborg vient du cadre Mollick. Le choix se fait selon l'auditoire — bionique pour les comex, cyborg pour les contextes techniques où le cadre Mollick est connu.

3. Locus de l'intention

Où se loge la décision sur quoi faire ? Trois positions : step-by-specification (l'humain dirige chaque étape), goal-specification (l'humain donne un but, l'IA décompose en étapes), system-specification (l'humain conçoit le système qui spécifie). Cet axe est probablement le plus structurant pour comprendre la transformation actuelle : à mesure que l'IA monte en autonomie, l'humain se déplace vers la spécification de système — il devient designer de processus plutôt qu'exécuteur.

4. Granularité de l'output

De quelle taille est l'unité produite ? Token (autocomplétion), fonction, module, feature, service, système. La granularité conditionne la nature de la revue humaine : on ne relit pas un système comme on relit une fonction.

5. Phase SDLC

Quelle phase du cycle de vie logiciel est touchée ? Spec, Design, Code, Test, Review, Deploy, Run, Maintain. Beaucoup d'offres se concentrent sur Code et Test ; les leviers les plus puissants sont souvent en amont (Spec, Design) ou en aval (Run, Maintain).

6. Périmètre de responsabilité

Cet axe caractérise le rôle plus que la pratique stricto sensu, mais il conditionne quelles pratiques un rôle applique. Tâche, feature, produit, ligne business. C'est ici que le Product Engineer se distingue du développeur augmenté — pas par l'outil, mais par le périmètre.

7. Compétences mobilisées

Ingénierie, produit, design, data, ops. La fusion de plusieurs compétences dans un même rôle est l'une des dynamiques majeures de l'ère agentique — précisément parce que l'IA compresse l'exécution technique, elle libère du temps pour les compétences adjacentes.

Inventaire des rôles, et le cas du Product Engineer

L'ontologie identifie sept rôles principaux. Aucun n'est exclusif : une même personne en endosse plusieurs selon les moments. Ce sont des positions, pas des étiquettes RH. Leur intérêt est de rendre lisibles les pratiques et les attentes — un développeur augmenté ne porte pas la même responsabilité qu'un Product Engineer, même s'ils utilisent le même outil.

Rôle	Intention dominante	Périmètre typique
Développeur augmenté	Step-by-specification	tâche · feature
Orchestrateur	Goal-specification	feature · produit
Ingénieur agentique	System-specification	produit · business
Product Engineer	Goal-specification	feature · produit
Vibe coder	Goal-specification	tâche · feature
Reviewer augmenté	Step-by-specification	feature · produit
Architecte augmenté	System-specification	produit · business

Le Product Engineer, un rôle structurant

Le Product Engineer mérite un développement particulier, car c'est un rôle qui prend une importance croissante à l'ère agentique. Définition :

Définition — Le Product Engineer est un ingénieur logiciel qui prend la responsabilité bout-en-bout d'un produit ou d'une fonctionnalité — depuis la formulation du problème utilisateur jusqu'à la mise en production et la mesure d'impact — en fusionnant les compétences traditionnellement réparties entre Product Manager, Designer et Software Engineer.

Là où l'ingénieur logiciel classique reçoit une spécification et livre du code, le Product Engineer possède l'intention : il décide quoi construire autant que comment le construire, en s'appuyant directement sur les signaux utilisateurs, les données d'usage et le jugement produit. C'est un rôle qui a émergé dans les startups à fort levier (Linear, Vercel, Ramp, Anthropic) et qui devient structurant à mesure que l'IA agentique compresse le coût de l'exécution technique. Quand la production de code n'est plus le goulot d'étranglement, c'est la qualité de la décision produit qui devient la valeur ajoutée.

Trois marqueurs distinctifs

• Raisonnement produit natif : formule des hypothèses, conçoit des expériences, lit la donnée d'usage.
• Sensibilité design : itère sur l'expérience sans attendre un Figma ou un handoff.
• Autonomie de livraison : ship en production sans handoff intermédiaire.

Dans l'ontologie, le Product Engineer est un rôle de premier rang, avec deux sous-classes : Product Engineer augmenté (outillé d'assistants IA, pattern centaure) et Product Engineer agentique (orchestre des agents pour livrer à l'échelle d'une équipe). La distinction n'est pas l'outil, c'est l'effet de levier.

Cette carte met en évidence un point souvent manqué : le Product Engineer n'est pas une évolution du développeur augmenté. Les deux rôles diffèrent moins par le niveau d'autonomie de l'IA que par le niveau d'autonomie décisionnelle de l'humain. Un Product Engineer augmenté qui ne pilote que de petits sprints reste un Product Engineer ; un développeur ultra-outillé qui n'arbitre rien sur le produit reste un développeur augmenté.

Pratiques : signatures et trajectoires

Une pratique se modélise comme un nœud caractérisé par sa signature à sept dimensions. Voici quelques pratiques de référence et leurs signatures abrégées :

Pratique	Autonomie	Mode	Intention	Granularité
Pair-programming IA	L1	cyborg	step	token / fonction
Spec-driven development	L2	centaure	step	fonction / module
Compound engineering	L3	centaure	goal	module / service
Vibe coding	L3	cyborg	goal	feature
End-to-end product delivery	L3	cyborg	goal	feature / module
Software Factory 10x	L4	centaure	system	système

La propriété :supersedes permet de modéliser une trajectoire entre pratiques : un client commence en pair-programming Copilot, monte en compound engineering avec Claude Code, puis bascule en Software Factory 10x. Cette trajectoire devient un actif narratif pour le commercial et un référentiel d'évaluation de maturité pour les équipes.

Une transformation AI for IT n'est pas une montée en autonomie de l'IA. C'est un déplacement du locus de l'intention humaine.

L'observation pratique qui en découle : les transformations qui réussissent ne sont pas celles qui « passent à L4 » le plus vite, mais celles qui font monter l'humain en abstraction décisionnelle au même rythme. Une équipe propulsée à L4 sans accompagnement sur le locus d'intention produit du code agentique massif et incohérent. Une équipe formée au goal-specification puis à la system-specification reste en contrôle même quand l'autonomie de l'IA augmente.

Systèmes IA : l'outillage qui active

Les systèmes IA sont modélisés comme des classes, pas comme des produits commerciaux. Cette abstraction protège l'ontologie de l'obsolescence : la classe Code Assistant reste valide quand Copilot sera remplacé par autre chose, comme la classe Foundation Model reste valide quel que soit le modèle de fondation du moment.

• Code Assistant — assistance à l'édition (Copilot, Tabnine, Codeium). Activent typiquement L1–L2.
• Agentic IDE — environnement où l'IA prend en charge des tâches multi-fichiers (Claude Code, Cursor agent, Windsurf). Activent L3.
• Autonomous Agent — agents qui exécutent un objectif sur un horizon long (Devin, agents internes). Activent L4–L5.
• Orchestration Layer — couche qui coordonne plusieurs agents et leur contexte (RAISE chez SFEIR, Conductor, frameworks d'orchestration). Activent L4.
• Foundation Model — modèle de base qui sous-tend toutes les couches précédentes (Claude, GPT, Gemini, modèles open weights).

Une pratique peut être activée par plusieurs systèmes — le compound engineering peut s'appuyer sur un Agentic IDE seul, ou sur un IDE + une couche d'orchestration. Cette flexibilité est volontaire : elle reflète la réalité opérationnelle.

Vue d'ensemble

Avant de passer au mode d'emploi, voici la cartographie consolidée de l'ontologie. Tous les composants présentés dans les sections précédentes y figurent, avec les relations qui les lient. C'est le schéma à garder sous les yeux quand on tague un contenu, qu'on cadre une offre ou qu'on rédige une requête SPARQL.

Utiliser l'ontologie dans votre KB

L'ontologie n'a de valeur que si elle est utilisée. Voici trois modes d'usage opérationnels.

Mode 1 — Tagger les contenus de la KB

Chaque article, étude de cas ou retour d'expérience peut être annoté avec les classes de l'ontologie. La structure recommandée en front-matter (Astro, Markdown ou autre) :

# front-matter d'un article de KB
title: "Migration legacy Java avec Claude Code"
ontology:
  role: Orchestrateur
  practice: LegacyModernization
  aiSystem: [AgenticIDE, FoundationModel]
  phase: [Design, Code, Test]
  autonomyLevel: L3_Délégation
  scope: ProductScope

Bénéfice : vous obtenez automatiquement des index par rôle, par pratique, par phase. Un visiteur intéressé par la modernisation legacy voit instantanément tous les retours d'expérience associés. Un commercial préparant un RDV filtre par scope=ProductScope + practice=LegacyModernization.

Mode 2 — Cadrer les offres

Chaque offre commerciale se décrit comme une combinaison {rôle cible, pratiques, systèmes}. Exemple :

# offre Software Factory 10x
targetRoles: [IngénieurAgentique, ProductEngineerAgentique]
enabledPractices: [CompoundEngineering, SoftwareFactory10x]
requiredSystems: [AgenticIDE, OrchestrationLayer]
supersedesPractices: [PairProgrammingIA]
phases: [Spec, Design, Code, Test, Deploy]

Cette description rend mécaniquement visible ce qui distingue deux offres. Un client comparant Software Factory 10x à un simple Copilot enablement voit que les rôles cibles sont différents, que les phases couvertes sont différentes, et que la première remplace ce que la seconde fait.

Mode 3 — Requêter en SPARQL

Si la KB est sérialisée en RDF/Turtle, on peut interroger l'ontologie. Quelques requêtes utiles :

# Toutes les pratiques de niveau L3 ou supérieur,
# orientées goal-specification
SELECT ?practice ?level WHERE {
  ?practice :hasAutonomyLevel ?level .
  ?practice :hasIntentionLocus :GoalSpecification .
  ?level :levelValue ?v .
  FILTER(?v >= 3)
}

# Tous les rôles qui couvrent la phase Design
SELECT DISTINCT ?role WHERE {
  ?role :appliesPractice ?p .
  ?p :participatesInPhase :Design .
}

# Trajectoire de transformation : pratiques qu'on peut
# atteindre depuis le pair-programming IA
SELECT ?next WHERE {
  ?next :supersedes+ :CopilotPairProgramming .
}

Mode 4 — Cartographier ses équipes

Au-delà des contenus, l'ontologie peut servir à cartographier les compétences. Pour chaque consultant ou équipe, on enregistre les rôles habituellement tenus, les pratiques maîtrisées, les systèmes utilisés. On obtient une vue agrégée : quelles pratiques sont déjà bien couvertes, lesquelles manquent, où former en priorité.

Bonne pratique — Ne pas confondre compétence à un moment t et capacité de progression. Un développeur augmenté peut devenir Product Engineer avec un accompagnement adéquat ; le rôle n'est pas un attribut figé. La cartographie sert à diagnostiquer, pas à étiqueter.

Enjeux et perspectives

Trois enjeux principaux émergent de la mise en pratique d'une telle ontologie.

Enjeu 1 — La tension entre stabilité et évolutivité

Le domaine AI for IT évolue vite. Une ontologie trop figée vieillit en six mois ; une ontologie trop fluide perd sa valeur de référentiel. La solution adoptée ici est une séparation par couches : les classes de haut niveau (Rôle, Pratique, Système IA) sont stables, leurs sous-classes peuvent évoluer, et les instances (pratiques nommées, outils précis) sont par nature versionnées. On préserve le squelette tout en laissant respirer la chair.

Enjeu 2 — Le risque d'appauvrissement

Toute ontologie simplifie. Le risque est de faire passer pour catégorisable ce qui ne l'est pas — la créativité d'un développeur, l'intuition produit d'un PE, la qualité d'une revue. L'ontologie n'a pas vocation à mesurer la valeur, elle structure le langage. Les jugements qualitatifs restent humains. Cette modestie est essentielle : elle évite de transformer un outil de clarification en grille d'évaluation tyrannique.

Enjeu 3 — L'adoption

Une ontologie qui ne sert qu'à elle-même est inutile. Pour qu'elle vive, il faut qu'elle soit visiblement utile au quotidien — qu'elle améliore les filtres de la KB, qu'elle clarifie les briefs commerciaux, qu'elle structure les retours d'expérience. L'adoption se construit en l'incorporant dans les outils existants, pas en demandant aux équipes de la consulter comme un document de référence.

Perspectives d'extension

Plusieurs extensions naturelles peuvent enrichir l'ontologie :

• Un axe risque et gouvernance pour adresser la dimension souveraineté, BATNA et conformité — particulièrement pertinent dans le contexte européen.
• Un alignement avec des ontologies existantes (SEON pour le software engineering, SWO pour le software ontology) afin de bénéficier de leur travail de modélisation.
• Une couche capacités commerciales qui mappe l'ontologie sur les familles d'expertise — chez SFEIR, les sept familles de couleurs du design system Sharp Artisan.
• Une intégration avec les référentiels RH classiques (compétences, niveaux de séniorité) pour articuler l'ontologie AI for IT avec les processus existants.

L'ontologie ne dit pas comment faire. Elle dit ce qu'on est en train de faire — et c'est déjà beaucoup.

Le bénéfice ultime n'est pas la structure formelle elle-même, c'est la conversation qu'elle rend possible. Quand deux équipes peuvent dire « nous sommes en compound engineering L3, locus goal, granularité module » plutôt que « nous faisons du dev augmenté », elles ne décrivent pas seulement la même chose mieux — elles peuvent comparer, transférer, faire évoluer. Et c'est précisément ce dont l'écosystème AI for IT a besoin pour mûrir au-delà de la mode.

L'ontologie en Turtle/OWL

Cette section présente le code complet de l'ontologie au format Turtle, prêt à être chargé dans Protégé, importé dans un triple store (Stardog, GraphDB, Apache Jena Fuseki, Oxigraph), ou requêté en SPARQL. Le code est aussi disponible en téléchargement direct : télécharger ai4it-ontology.ttl.

La structure suit les sept modules présentés au fil de l'article. Chaque module est indépendant : vous pouvez en charger une partie seulement si votre cas d'usage ne nécessite pas l'ontologie complète. Les déclarations de préfixes en tête doivent en revanche toujours figurer.

Préambule — Préfixes

@prefix :     <https://sfeir.com/ontology/ai4it#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

Module 1 — Agents

Trois types d'agents : humain, IA pur, ou système hybride humain+IA agissant comme une unité.

:Agent          a owl:Class .
:HumanAgent     rdfs:subClassOf :Agent .
:AIAgent        rdfs:subClassOf :Agent .
:HybridSystem   rdfs:subClassOf :Agent ;
    rdfs:comment "Système humain+IA agissant comme une unité"@fr .

Module 2 — Rôles

Sept rôles principaux, avec le Product Engineer décliné en deux spécialisations selon l'effet de levier IA.

:Role a owl:Class .

:DéveloppeurAugmenté    rdfs:subClassOf :Role ;
    rdfs:comment "IA en assistance, humain au centre, pattern centaure"@fr .

:Orchestrateur          rdfs:subClassOf :Role ;
    rdfs:comment "Pilote un ou plusieurs agents IA"@fr .

:IngénieurAgentique     rdfs:subClassOf :Role ;
    rdfs:comment "Conçoit et opère le système d'agents lui-même"@fr .

:VibeCoder              rdfs:subClassOf :Role ;
    rdfs:comment "Spécifie l'intention, l'IA produit le code"@fr .

:ReviewerAugmenté       rdfs:subClassOf :Role .
:ArchitecteAugmenté     rdfs:subClassOf :Role .
:OpsAugmenté            rdfs:subClassOf :Role .

# Product Engineer et ses spécialisations
:ProductEngineer rdfs:subClassOf :Role ;
    rdfs:label "Product Engineer"@fr ;
    rdfs:comment """Ingénieur portant la responsabilité bout-en-bout
        d'un produit ou d'une fonctionnalité, de la formulation du
        problème utilisateur à la mise en production et la mesure
        d'impact. Fusionne ingénierie, design et raisonnement produit."""@fr ;
    skos:related :IngénieurAgentique, :ArchitecteAugmenté .

:ProductEngineerAugmenté  rdfs:subClassOf :ProductEngineer ;
    rdfs:comment "PE outillé d'assistants IA, ship en pattern centaure"@fr .

:ProductEngineerAgentique rdfs:subClassOf :ProductEngineer ;
    rdfs:comment "PE orchestrant des agents pour livrer à l'échelle d'une équipe"@fr .

Module 3 — Axes orthogonaux

Sept dimensions indépendantes qui caractérisent une pratique. Le module est subdivisé en sous-axes (3a à 3g).

# --- 3a. Niveau d'autonomie de l'IA ---
:AutonomyLevel a owl:Class .
:L0_Manual       a :AutonomyLevel ; :levelValue 0 ; rdfs:label "Manuel"@fr .
:L1_Assistance   a :AutonomyLevel ; :levelValue 1 ; rdfs:label "Autocomplétion"@fr .
:L2_Augmentation a :AutonomyLevel ; :levelValue 2 ; rdfs:label "Génération sur demande"@fr .
:L3_Délégation   a :AutonomyLevel ; :levelValue 3 ; rdfs:label "Tâches entières déléguées"@fr .
:L4_Agentique    a :AutonomyLevel ; :levelValue 4 ; rdfs:label "Multi-étapes supervisé"@fr .
:L5_Autonome     a :AutonomyLevel ; :levelValue 5 ; rdfs:label "Bout-en-bout sans supervision"@fr .

# --- 3b. Mode de collaboration (Mollick) ---
:CollaborationMode a owl:Class .
:Centaur a :CollaborationMode ; rdfs:comment "Tâches séparées humain/IA"@fr .
:Cyborg  a :CollaborationMode ; rdfs:comment "Intégration fluide, fusionnée"@fr .

# --- 3c. Locus de l'intention ---
:IntentionLocus a owl:Class .
:StepBySpecification a :IntentionLocus ;
    rdfs:comment "L'humain dirige chaque étape"@fr .
:GoalSpecification a :IntentionLocus ;
    rdfs:comment "L'humain spécifie le but, l'IA décompose"@fr .
:SystemSpecification a :IntentionLocus ;
    rdfs:comment "L'humain conçoit le système qui spécifie"@fr .

# --- 3d. Granularité de l'output ---
:Granularity a owl:Class .
:Token    rdfs:subClassOf :Granularity .
:Function rdfs:subClassOf :Granularity .
:Module   rdfs:subClassOf :Granularity .
:Feature  rdfs:subClassOf :Granularity .
:Service  rdfs:subClassOf :Granularity .
:System   rdfs:subClassOf :Granularity .

# --- 3e. Phase SDLC ---
:SDLCPhase a owl:Class .
:Spec     rdfs:subClassOf :SDLCPhase .
:Design   rdfs:subClassOf :SDLCPhase .
:Code     rdfs:subClassOf :SDLCPhase .
:Test     rdfs:subClassOf :SDLCPhase .
:Review   rdfs:subClassOf :SDLCPhase .
:Deploy   rdfs:subClassOf :SDLCPhase .
:Run      rdfs:subClassOf :SDLCPhase .
:Maintain rdfs:subClassOf :SDLCPhase .

# --- 3f. Périmètre de responsabilité ---
:ResponsibilityScope a owl:Class .
:TaskScope     a :ResponsibilityScope ; rdfs:label "Tâche"@fr .
:FeatureScope  a :ResponsibilityScope ; rdfs:label "Feature"@fr .
:ProductScope  a :ResponsibilityScope ; rdfs:label "Produit"@fr .
:BusinessScope a :ResponsibilityScope ; rdfs:label "Ligne business"@fr .

# --- 3g. Compétences mobilisées ---
:Competency a owl:Class .
:EngineeringCompetency rdfs:subClassOf :Competency .
:ProductCompetency     rdfs:subClassOf :Competency .
:DesignCompetency      rdfs:subClassOf :Competency .
:DataCompetency        rdfs:subClassOf :Competency .
:OpsCompetency         rdfs:subClassOf :Competency .

Module 4 — Pratiques

Sept pratiques de référence. Cette liste est extensible : chaque organisation peut ajouter ses propres pratiques en sous-classe de :Practice.

:Practice a owl:Class .
:PairProgrammingIA       rdfs:subClassOf :Practice .
:SpecDrivenDevelopment   rdfs:subClassOf :Practice .
:CompoundEngineering     rdfs:subClassOf :Practice .
:VibeCoding              rdfs:subClassOf :Practice .
:AgenticRefactoring      rdfs:subClassOf :Practice .
:LegacyModernization     rdfs:subClassOf :Practice .
:EndToEndProductDelivery rdfs:subClassOf :Practice ;
    rdfs:label "Livraison produit bout-en-bout"@fr ;
    rdfs:comment "Pratique caractéristique du Product Engineer"@fr .

Module 5 — Systèmes IA

Cinq classes d'outils. Les noms commerciaux (Copilot, Claude Code, Devin…) sont des instances de ces classes, pas des classes elles-mêmes — ce qui protège l'ontologie de l'obsolescence.

:AISystem a owl:Class .
:CodeAssistant      rdfs:subClassOf :AISystem .   # Copilot, Tabnine
:AgenticIDE         rdfs:subClassOf :AISystem .   # Claude Code, Cursor
:AutonomousAgent    rdfs:subClassOf :AISystem .   # Devin
:OrchestrationLayer rdfs:subClassOf :AISystem .   # RAISE, Conductor
:FoundationModel    rdfs:subClassOf :AISystem .   # Claude, GPT, etc.

Module 6 — Artefacts

Les sorties produites par les pratiques. Liste minimale, à étendre selon les besoins (deck, ADR, runbook, etc.).

:Artifact a owl:Class .
:Code                 rdfs:subClassOf :Artifact .
:Specification        rdfs:subClassOf :Artifact .
:TestSuite            rdfs:subClassOf :Artifact .
:ArchitectureDecision rdfs:subClassOf :Artifact .
:Documentation        rdfs:subClassOf :Artifact .

Module 7 — Propriétés

Les relations qui structurent l'ontologie. Le découpage domain / range garantit qu'un raisonneur OWL peut détecter les incohérences (par exemple un :Role branché sur un :AutonomyLevel).

# Propriétés principales
:hasRole              a owl:ObjectProperty ; rdfs:domain :HumanAgent ; rdfs:range :Role .
:appliesPractice      a owl:ObjectProperty ; rdfs:domain :Agent ;     rdfs:range :Practice .
:enabledBy            a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :AISystem .
:hasAutonomyLevel     a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :AutonomyLevel .
:hasCollaborationMode a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :CollaborationMode .
:hasIntentionLocus    a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :IntentionLocus .
:hasGranularity       a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :Granularity .
:participatesInPhase  a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :SDLCPhase .
:produces             a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :Artifact .
:supersedes           a owl:ObjectProperty ; rdfs:domain :Practice ;  rdfs:range :Practice .

# Propriétés liées au rôle
:hasResponsibilityScope a owl:ObjectProperty ; rdfs:domain :Role ; rdfs:range :ResponsibilityScope .
:requiresCompetency     a owl:ObjectProperty ; rdfs:domain :Role ; rdfs:range :Competency .

Mode d'emploi du fichier

Charger l'ontologie

Dans Protégé : File → Open → sélectionner ai4it-ontology.ttl. Activer un raisonneur (HermiT ou Pellet) pour bénéficier de l'inférence sur les hiérarchies de classes.

Dans un triple store : charger le fichier dans un graphe nommé, par exemple https://sfeir.com/graphs/ai4it, puis interroger via SPARQL endpoint.

Dans une application : utiliser une bibliothèque RDF (rdflib en Python, Apache Jena en Java, rdf-ext en JavaScript) pour parser le fichier et exposer les classes/propriétés à votre couche métier.

L'ontologie est versionnée. Toute modification du squelette (ajout d'axe, modification d'une propriété) doit déclencher une nouvelle version ; l'ajout d'instances (nouvelles pratiques nommées, nouveaux outils) ne nécessite qu'un incrément mineur. Pour les contributions, suivre le principe : les classes de haut niveau sont stables, leurs sous-classes peuvent évoluer, les instances sont par nature versionnées.