Structurez votre IA pour le code ou pour les modèles. Livrez en confiance.

CognitiveSDD

---

Développement logiciel

Le problème

En développement logiciel, les assistants de codage IA sont puissants, mais sans structure ils produisent des résultats fragiles. Les développeurs promptent, obtiennent du code, promptent encore, et se retrouvent avec un logiciel sans exigences traçables, sans justification architecturale, et sans garantie que ce qui a été construit correspond à ce qui était nécessaire. Quand quelque chose casse, il n'y a aucune piste. Quand les exigences changent, il n'y a aucun protocole d'adaptation contrôlée. Le résultat : du « vibe coding » — rapide mais fragile.

La solution

Pour les développeurs de logiciels, CognitiveSDD orchestre un workflow structuré à travers la découverte de user stories, la dérivation d'exigences, la conception architecturale avec ADR, la spécification de tests avec marqueurs de traçabilité, l'implémentation autonome dans des conteneurs protégés par pare-feu et la vérification complète — produisant du code source, des suites de tests automatisés et un build traçable où chaque test renvoie à son exigence.

Phases — projet logiciel

Phase	Livrable
Setup	Projet scaffoldé avec structure idiomatique au langage, fichiers de build et organisation prête pour la CI
User Stories	Découverte structurée par questionnement et recherche web, produisant des user stories validées
Exigences	Exigences fonctionnelles et non fonctionnelles conformes INCOSE, vérifiées contre les ambiguïtés, clauses d'échappatoire, voix passive
Architecture	Propositions de conception section par section avec dossiers de décisions architecturales (ADR)
Specs de tests	Stubs de tests pré-câblés avec des marqueurs de traçabilité @req reliant chaque test à son exigence
Implémentation	Codage autonome contre la spec, avec verrouillage total de git et pare-feu réseau
Vérification	Matrice de traçabilité complète, tous les tests au vert, analyse des écarts, rapport de dette technique, vérification de cohérence
Mise à jour	Boucle de changement par ticket — analyse d'impact, ré-exécution ciblée, vérification

---

Ingénierie système (MBSE)

Le problème

La même dérive affecte l'adoption du MBSE. Les exigences vivent dans Word, l'architecture dans Visio, la vérification dans Excel, l'analyse dans un notebook dont personne n'est propriétaire. SysML v2 — la spécification OMG où requirement def, verification case def, satisfy et verify sont des éléments de langage de première classe — promet de régler cela. Mais les équipes qui l'adoptent rencontrent le même problème : pas de portes de phase, pas de discipline de traçabilité imposée, pas de protocole d'amendement quand une décision d'architecture invalide une exigence antérieure, pas de vérification automatique de l'ambiguïté dans le texte des exigences.

La solution

Pour les ingénieurs système, CognitiveSDD applique la même discipline de phases verrouillées à l'ingénierie système basée sur les modèles. L'orchestrateur guide l'IA à travers l'élicitation des besoins parties prenantes, les exigences conformes INCOSE (matérialisées comme éléments requirement def), l'architecture structurelle (part def, ports, interfaces), les specs de vérification (verification case def) et la modélisation comportementale — produisant un modèle SysML v2 complet avec traçabilité de bout en bout des exigences aux cas de vérification.

Phases — projet d'ingénierie (MBSE)

Phase	Livrable
Setup	Arbre MBSE scaffoldé, Bibliothèque Standard vendorée, outillage pinné
Besoins parties prenantes	Élicitation structurée des besoins système et cas d'usage
Exigences	Exigences conformes INCOSE matérialisées comme éléments requirement def avec require constraint
Architecture	Modèle structurel (part def hiérarchisé, ports, interfaces, allocations), avec ADR
Specs de vérification	Stubs verification case def avec clauses verify requirement pour chaque exigence Must
Modélisation	Modèle comportemental et analytique (action def, state def, calc def, constraint def)
Vérification	Parse-validate par l'outillage, exécution des verification case, couverture des exigences, rapport réussite/échec
Mise à jour	Même boucle de changement par ticket, ciblée sur les éléments du modèle

---

Sous le capot : Le moteur haute intégrité

Bien que les livrables, les modèles de scaffolding, les prompts de phase et les règles qualité soient adaptés soit au logiciel soit à l'ingénierie système, les deux cas d'usage partagent un cœur technique robuste conçu pour la sécurité en profondeur, une traçabilité mathématique stricte et un contrôle de phase déterministe.

Fonctionnalités clés du moteur

• Moteur de workflow à graphe orienté. Les étapes sont des nœuds dans un graphe orienté, pas des éléments d'une liste. Le moteur supporte les transitions arrière, la détection de boucles avec limites configurables, la récupération après crash et les workflows paramétrés avec variables d'exécution.

• Sécurité conteneur en profondeur. L'IA s'exécute dans un conteneur Docker / Podman avec un pare-feu iptables en politique par défaut de rejet, n'autorisant QUE l'API du fournisseur IA. GitHub, npm, PyPI et tout internet général sont bloqués au niveau du noyau. Un hook pré-exécution bloque TOUTES les commandes git. Un agent git côté hôte gère toute la gestion de version. Un conteneur de recherche séparé fournit l'accès internet pour la recherche web mais ne peut pas voir le code source ni le modèle.

• Linting des exigences INCOSE. Un validateur automatisé détecte les verbes ambigus, les clauses d'échappatoire, les quantificateurs vagues, la voix passive, les références non qualifiées et les détails d'implémentation qui relèvent de l'architecture — pas des exigences.

• Traçabilité complète. Chaque exigence se prolonge jusqu'aux tests et au code source (logiciel) ou jusqu'aux cas de vérification et éléments de modèle satisfaisants (ingénierie) via les marqueurs @req. Une base de traçabilité événementielle se met à jour de manière incrémentale après chaque tour IA. Résumés de couverture, détection d'orphelins et un outil MCP interrogeable offrent une visibilité instantanée.

• Portes de phase avec critères de sortie. Sept types de critères (file_exists, dir_nonempty, file_contains, command_succeeds, user_approves, ai_validates, coherence_check) avec logique de réessai. L'IA ne peut pas avancer silencieusement avec un travail incomplet.

• Protocole d'amendement. À partir de la phase d'architecture, si un agent découvre un conflit avec un artefact validé, il s'arrête, documente le problème, propose un correctif et attend l'approbation humaine. Aucune déviation silencieuse — jamais.

• Suivi de la dette technique. Un scanner de dette automatisé s'exécute à chaque porte utilisateur. La dette critique bloque les transitions de phase. Les projets d'ingénierie étendent le catalogue avec des catégories de dette modèle : exigences orphelines, contraintes vides, liens verify manquants.

• Agent git automatisé. Un agent git côté hôte commit et pousse à chaque frontière d'étape. Le retour à n'importe quel point du workflow est un simple git checkout.

• L'humain dans la boucle par conception. Le rôle de l'utilisateur se réduit à trois activités : écrire la description du projet, revoir et approuver aux portes, et soumettre des demandes de changement. Tout le reste est automatisé.

Modes de workflow

• Greenfield — nouveaux projets à partir d'une description (logiciel ou ingénierie)
• Brownfield — rétro-ingénierie et amélioration d'artefacts existants
• Gestion du changement — demandes de changement post-déploiement avec analyse d'impact et routage ciblé

À qui ça s'adresse

• Développeurs solo et petites équipes logicielles qui veulent livrer des logiciels entièrement documentés, testés et traçables à un rythme qui nécessite normalement un département d'ingénierie complet.
• Ingénieurs système et équipes MBSE qui adoptent SysML v2 et qui veulent des portes de phase, une discipline d'exigences conforme INCOSE, une traçabilité de bout en bout et un protocole d'amendement.
• Ingénieurs en environnements critiques et réglementés (aérospatial, automobile, médical, défense) qui ont besoin d'artefacts auditables, alignés INCOSE.
• Organisations soucieuses de la sécurité qui exigent que les agents IA opèrent dans des limites de sécurité en profondeur — pas seulement un sandbox, mais un sandbox protégé par pare-feu avec verrouillage total du contrôle de version.

Comment ça fonctionne

1. Installez CognitiveSDD et lancez csdd doctor pour vérifier les prérequis.
2. Lancez csdd run dans votre répertoire de projet. L'assistant demande la catégorie, le langage, les personas et les seuils.
3. Décrivez votre projet en un paragraphe.
4. Le moteur de workflow lance un conteneur protégé par pare-feu pour chaque étape. L'IA travaille de manière autonome. L'agent git commit à chaque frontière.
5. À chaque porte, revoyez les artefacts, approuvez, rejetez avec feedback ou demandez des amendements.
6. Livrez du logiciel avec traçabilité complète de l'exigence au test au code — ou livrez un modèle SysML v2 avec traçabilité complète de l'exigence au cas de vérification à l'élément de modèle.

Après déploiement, soumettez des demandes de changement via csdd run --workflow change --var change_id=CR-001.