Développer avec l'IA sans faire du vibe coding : l'architecture d'ingénierie de SecuAAS
Auteur : Olivier Lange, Président Fondateur — Les Entreprises SecuAAS Inc.
Date : Avril 2026 | Temps de lecture : 12 minutes
Introduction
Il y a 18 mois, je codais seul. Aujourd'hui, 10 agents IA travaillent en parallèle sur nos produits de cybersécurité, poussent du code en production sur des clusters Kubernetes, et opèrent sur 79 repositories.
Quand j'ai partagé ce constat sur LinkedIn, les échanges qui ont suivi — en privé, avec des partenaires, des investisseurs potentiels, des confrères en cybersécurité — ont fait remonter une question récurrente : « C'est pas du vibe coding, ça ? »
C'est une question légitime. Et plutôt que d'y répondre au cas par cas, j'ai décidé d'y répondre en profondeur, publiquement, pour tuer le doute dans l'œuf. Pas une défense émotionnelle, mais une démonstration factuelle de notre architecture d'ingénierie. Parce que la question n'est pas « utilisez-vous l'IA pour coder ? » — tout le monde le fera bientôt. La question est : comment gouvernez-vous l'IA qui code ?
Le problème du vibe coding
Le vibe coding, c'est utiliser un LLM comme un générateur de code sans contexte, sans contraintes et sans validation. On tape un prompt vague, on copie le résultat, on prie pour que ça fonctionne.
C'est exactement ce que nous ne faisons pas.
Chez SecuAAS, chaque agent IA opère à l'intérieur d'un système d'ingénierie que j'ai conçu et que je gouverne. L'IA est un acteur d'exécution contrôlé — pas un développeur autonome. La distinction est fondamentale et elle se manifeste à chaque couche de notre stack.
Couche 1 — La spécification humaine comme contrat
Chaque tâche de développement commence par un fichier .md rédigé par un humain. Ce fichier est un contrat technique qui contient le contexte du changement, l'objectif précis, les critères d'acceptation mesurables, les contraintes techniques (repos concernés, APIs à utiliser, patterns à respecter) et les conditions de blocage.
L'agent n'interprète pas une intention floue. Il exécute une spécification. C'est la différence entre demander « fais-moi un formulaire » et fournir un document de 50 lignes qui décrit les champs, les validations, les endpoints API, les cas d'erreur et les tests attendus.
Ce que j'ai appris : un agent mal briefé coûte plus cher qu'un développeur mal briefé. Le vrai travail, c'est la conception des tâches, pas l'exécution. C'est un changement de posture complet pour le fondateur technique : on passe de « celui qui code » à « l'architecte qui spécifie et gouverne ».
Couche 2 — Le dispatcher : orchestration déterministe
Le dispatcher est le chef d'orchestre du système. C'est un processus bash qui tourne en cron, scanne les inbox de tâches, et distribue le travail aux agents via des sessions tmux dédiées.
Son fonctionnement est délibérément déterministe, pas créatif :
Triage GPU — Avant d'assigner une tâche, notre propre GPU souverain (Qwen 3.5, hébergé sur OVH Beauharnois) analyse la complexité, sélectionne le modèle LLM approprié (les tâches triviales n'ont pas besoin du même modèle qu'une refonte architecturale), et évalue le niveau de risque.
Gestion de quota — Le dispatcher gère automatiquement la rotation entre comptes API, détecte les limites de quota, et switche sans intervention humaine. Un mécanisme anti-boucle (retry counters par tâche, cooldown par projet) empêche les agents de tourner indéfiniment sur une tâche bloquée.
Parallélisation contrôlée — Jusqu'à 10 agents travaillent simultanément sur des repos différents (sessions ccl-auto-11 à ccl-auto-20). Chaque session est isolée dans son projet, avec son propre contexte git.
Résultat : les tâches s'exécutent en parallèle, sur des produits différents, sans conflit, sans intervention humaine pendant l'exécution — mais avec une traçabilité complète.
Couche 3 — La gate de production : zéro deploy sans approbation
C'est ici que la gouvernance se durcit. Aucun code ne touche l'environnement de production sans passer par notre système de gate.
Le flux est le suivant. L'agent complète une tâche et pousse sur la branche main (qui déploie sur k8s-dev). Un script validate-e2e.sh exécute les tests automatisés. Une review GPU analyse le code produit (qualité, patterns, risques). La tâche entre dans un état awaiting-prod visible dans notre orchestrateur. L'humain (moi) approuve ou rejette, avec une raison documentée. Seulement alors, le deploy en production est déclenché.
Chaque décision de gate (approve/reject) est enregistrée avec un horodatage et une raison. C'est un audit trail complet. Un investisseur ou un auditeur peut retracer exactement quel code est passé en production, quand, pourquoi, et qui a approuvé.
L'outil deploy_risk effectue une analyse de risque avant chaque mise en production : détection de breaking changes, besoin de migration de données, plan de rollback.
Couche 4 — Sécurité intégrée : scanner ce que l'IA produit
Faire coder par l'IA sans scanner ce qu'elle produit serait de la négligence. Nous avons intégré la sécurité à trois niveaux.
Scanyze EASM — Scanner sa propre surface d'attaque
Scanyze, notre plateforme EASM (External Attack Surface Management), est notre produit phare. Mais nous l'utilisons aussi sur nous-mêmes. Plus de 22 outils de scan réseau tournent sur notre infrastructure : Nmap, Nuclei, Subfinder, TestSSL, DNS Audit, et d'autres. Chaque sous-domaine, chaque port exposé, chaque certificat est monitoré en continu.
L'idée est simple : si un agent IA crée un service avec un port exposé non prévu, ou une configuration TLS faible, le scan EASM le détecte avant qu'un attaquant ne le trouve.
Code scanning — 19 moteurs d'analyse statique
Le code produit par nos agents passe par 19 moteurs d'analyse. SAST (Static Application Security Testing) avec Semgrep et gosec. SCA (Software Composition Analysis) avec Trivy pour les dépendances vulnérables. Détection de secrets avec Gitleaks et TruffleHog. Analyse IaC (Infrastructure as Code) pour les manifests Kubernetes.
Chaque finding est ensuite analysé par notre IA souveraine (Qwen 3.5 sur notre GPU) pour trier les vrais positifs des faux positifs et générer des suggestions de remédiation contextualisées. Ce n'est pas un simple rapport — c'est une analyse intelligente qui comprend le contexte du code.
Harbor — Scan d'images conteneur
Chaque image Docker buildée passe par notre registry Harbor privé, hébergé sur OVH Beauharnois (BHS5). Harbor effectue un scan de vulnérabilités automatique sur chaque image poussée. Une image avec des CVE critiques ne devrait pas être déployée.
Le registre est privé, les images sont taggées par version sémantique (pas de latest en production pour les services critiques), et les credentials sont gérées via des secrets Kubernetes impératifs (jamais en clair dans le code).
Ce triple scan — surface externe, code source, images conteneur — crée une boucle de sécurité complète autour de tout ce que l'IA produit.
Couche 5 — Observabilité : watchdog, BetaWatch et monitoring
Watchdog infrastructure
Un watchdog tourne 24/7 et surveille l'état des agents, du GPU, des services Kubernetes et de la base de données. En cas d'anomalie, il tente d'abord une réparation automatique. Si la réparation échoue, il escalade via Telegram (9 topics de notification dans notre groupe infra).
Le watchdog est conçu pour détecter les situations que l'IA ne peut pas voir : un agent qui tourne en boucle sans produire de résultat, un pod en CrashLoopBackOff, un GPU qui ne répond plus, un connection pool de base de données saturé.
BetaWatch — Boucle de feedback automatisée
BetaWatch est notre système de capture de bugs et de télémétrie, intégré en widget JavaScript dans chaque application. En mode passif, il capture les erreurs JavaScript, les erreurs réseau, les Web Vitals. En mode actif, il offre un formulaire de signalement (bug, suggestion, question).
Ce qui rend BetaWatch unique dans notre contexte : chaque bug capturé est automatiquement trié, dédupliqué par fingerprint, et peut être routé vers un agent pour correction automatique. Les commits de fix sont préfixés fix(betawatch): resolve event #XXXXX pour la traçabilité.
La boucle est fermée : bug détecté → tâche créée → agent corrige → deploy via gate → bug résolu. Avec un humain dans la boucle à l'étape d'approbation.
SecuDebug — Le war room IA pour bugs complexes
BetaWatch gère le volume : détection passive, queue, correction automatique. Mais certains bugs ne se résolvent pas avec une tâche en file d'attente. Un problème d'authentification intermittent, un race condition sous charge, un bug qui n'apparaît qu'en production avec des données réelles — ça demande une investigation en temps réel.
C'est le rôle de SecuDebug, notre plateforme de debugging live augmentée par IA.
SecuDebug ouvre une session de debugging interactive via une extension Chrome (Side Panel). Dès l'ouverture, trois flux convergent en temps réel : les logs serveur (streamés depuis notre SIEM via Loki), les logs browser (capturés par un content script injecté dans la page), et le code source (cloné depuis Forgejo).
Deux LLM analysent simultanément : Claude Opus pour le raisonnement profond, et Gemini pour une perspective complémentaire. Si les deux modèles convergent sur un diagnostic, un patch unique est proposé. S'ils divergent, chacun voit la réponse de l'autre pour un tour supplémentaire. En cas de désaccord persistant, les deux options sont présentées à l'humain qui tranche.
Le patch validé est committé sur une branche dédiée (secudebug/fix-{id}), les tests tournent automatiquement, et si tout passe, le déploiement se fait en continu — le tout sans quitter la session de debug. Chaque commit porte les métadonnées de traçabilité : qui a validé, quels modèles ont analysé, quels fichiers ont été modifiés.
Ce n'est pas de l'IA autonome. C'est un outil de diagnostic où l'humain reste décideur à chaque étape, mais où l'IA accélère l'analyse d'un facteur 10 en croisant logs, code et contexte en temps réel.
QA automatisé — Vrai navigateur, vrais tests
BetaWatch capture ce que les utilisateurs signalent. SecuDebug résout ce qui est complexe. Mais aucun des deux ne remplace une suite de tests automatisés qui navigue réellement dans l'application.
Notre QA automatisé tourne sur une VM dédiée avec Opera Neon (navigateur Chromium) piloté par un agent Claude Opus. Contrairement aux tests headless classiques, l'agent exécute de vrais scénarios fonctionnels dans un vrai navigateur : navigation multi-pages, formulaires, authentification SSO, upload de fichiers, flux e-commerce. Chaque run génère un rapport structuré (JSON + screenshots) avec les régressions détectées, les temps de chargement, et les erreurs réseau.
Les rapports sont analysés automatiquement : si une régression est détectée sur un flux critique (login, checkout, upload), une tâche est créée dans l'agent queue pour correction. Comme BetaWatch, la boucle est fermée — mais au niveau fonctionnel, pas seulement au niveau des erreurs JavaScript.
Stack de monitoring
Prometheus, Grafana, Loki, Fluent Bit, Alertmanager avec notifications SMS (Telnyx), Wazuh pour le SIEM. L'observabilité n'est pas une option quand l'IA pousse du code — c'est une obligation.
Couche 6 — Souveraineté des données : pourquoi ça compte pour un investisseur
Tout ce qui précède tourne sur une infrastructure 100% hébergée au Canada, chez OVH Beauharnois (Québec). Pas AWS. Pas Azure. Pas GCP.
Pourquoi ? La Loi 25 du Québec impose des obligations strictes sur la protection des renseignements personnels. Le CLOUD Act américain permet aux autorités US d'accéder aux données hébergées par des fournisseurs américains, même si les serveurs sont physiquement au Canada.
En hébergeant exclusivement sur OVH (entreprise française avec datacenters au Québec), nous éliminons cette exposition juridique. C'est un différenciateur commercial concret pour nos clients, et une garantie de conformité réglementaire pour nos investisseurs.
Notre GPU souverain (NVIDIA V100S 32 Go, Qwen 3.5) signifie que même l'IA qui analyse le code et trie les bugs ne fait jamais sortir les données du pays. La souveraineté s'applique à l'orchestration aussi.
L'infrastructure en chiffres
Pour ceux qui veulent du concret, voici l'état de notre infrastructure de production en avril 2026 :
Kubernetes — 2 clusters OVH Managed (dev + prod), 5 nodes de calcul + 1 node GPU (V100S). Plus de 100 pods en production, 25+ applications déployées, 0 restart non planifié sur les services critiques.
Repositories — 79 repos sur Forgejo (auto-hébergé, migré depuis GitHub). Chaque repo a son workflow CI/CD via Forgejo Actions. Les builds sont poussés vers le registry Harbor OVH BHS5.
Base de données — PostgreSQL managé OVH (BHS), partagé entre tous les produits avec isolation par schema. Valkey managé (compatible Redis) pour le caching.
GPU — V100S 32 Go tournant Qwen 3.5-35B en inférence permanente via vLLM (~84 tokens/seconde). Utilisé pour l'analyse IA de Scanyze, le triage des tâches, la review de code, et la corrélation SIEM.
Serveur dédié — Proxmox VE9 (Xeon E-2288G, 64 Go RAM, 2×960 Go NVMe, 10 Gbps) hébergeant Forgejo, le MCP server, l'orchestrateur de développement et le VPN WireGuard.
Ce que ça signifie pour un investisseur
Si vous êtes investisseur en capital-risque et que vous évaluez SecuAAS, voici les points clés.
Vélocité sans dette technique — Nous livrons à la vitesse de 10 développeurs, avec la rigueur d'une équipe d'ingénierie structurée. Chaque ligne de code est tracée, testée, scannée et approuvée.
Coût de développement optimisé — L'IA réduit drastiquement le coût par feature. Notre burn rate est celui d'une équipe de 3 personnes, notre output est celui d'une équipe de 15.
Sécurité vérifiable — Triple couche de scan (EASM, code, images), audit trail des déploiements, gate de production avec approbation humaine. Ce n'est pas une promesse — c'est une architecture.
Souveraineté réglementaire — Infrastructure 100% canadienne, conforme Loi 25, aucune exposition CLOUD Act. Un actif stratégique sur le marché québécois et canadien.
Scalabilité prouvée — L'architecture supporte déjà 25+ applications en production. Ajouter un nouveau produit SaaS ne requiert pas d'embaucher 5 développeurs — il faut spécifier les tâches et laisser le système d'agents les exécuter.
Conclusion
Le vibe coding, c'est l'équivalent logiciel de construire un immeuble sans plans, sans inspecteur, et sans permis. Ça peut donner un prototype impressionnant, mais personne de sérieux ne va y investir.
Ce que nous avons construit chez SecuAAS, c'est l'inverse : un système d'ingénierie où l'IA est un outil puissant mais contrôlé, opérant à l'intérieur de contraintes strictes de spécification, de validation, de sécurité et de gouvernance.
Ce n'est pas de la magie. C'est de l'architecture.
Ce que l'IA ne remplacera jamais : l'expertise qui gouverne
C'est ici qu'il faut être direct.
N'importe quel développeur peut brancher un LLM sur un repository et générer du code. Les outils sont accessibles, les APIs sont documentées, les tutoriels sont partout. En 2026, faire coder une IA est devenu trivial.
Ce qui n'est pas trivial, c'est de savoir pourquoi il faut scanner chaque image conteneur avant de la pousser au registry. C'est de comprendre qu'un SecurityContext manquant sur un pod Kubernetes est une escalade de privilèges en attente. Que des secrets en clair dans un pipeline CI sont un incident qui n'a pas encore eu lieu. Qu'un connection pool mal dimensionné va saturer sous charge et cascader sur tous les services dépendants. Que le CLOUD Act rend juridiquement vulnérable tout client dont les données transitent par un hyperscaler américain.
Ces réflexes ne viennent pas d'un prompt. Ils viennent de 25 ans à déployer des infrastructures, à répondre à des incidents de sécurité à 3h du matin, à auditer des architectures d'entreprise, à comprendre ce qui casse en production et pourquoi.
Quand j'ai conçu le système de gate avec approbation humaine, ce n'est pas parce que c'est « best practice » — c'est parce que j'ai vu des déploiements automatiques détruire des environnements de production. Quand j'ai imposé le triple scan (EASM, code source, images conteneur), ce n'est pas par excès de prudence — c'est parce que j'ai audité des entreprises qui avaient des CVE critiques non patchées dans leurs images Docker depuis des mois sans le savoir. Quand j'ai bâti le watchdog avec retry counters et escalade Telegram, c'est parce qu'un agent IA en boucle infinie peut brûler un budget API en heures — et que personne n'en parle dans les démos.
La différence entre un projet « propulsé par l'IA » et une entreprise d'ingénierie qui utilise l'IA, c'est exactement celle-là : la profondeur de l'expertise qui définit les contraintes du système.
Un développeur junior avec ChatGPT peut produire un prototype en un week-end. Un professionnel de la cybersécurité avec une maîtrise en informatique, 25 ans d'expérience en infrastructure et en développement, va produire une solution commercialisable en production — avec le système de gouvernance, de sécurité et d'observabilité qui la rend déployable, auditable et investissable. Pas un prototype. Pas un MVP. Un produit complet, avec une roadmap d'évolution, des clients en beta payante, et une infrastructure qui tient la charge.
C'est la barrière à l'entrée réelle de SecuAAS. Pas l'IA — tout le monde y a accès. La compétence pour la gouverner.
Olivier Lange est fondateur de SecuAAS, entreprise québécoise de cybersécurité souveraine. 25 ans d'expérience en TI et cybersécurité. Maîtrise en informatique.
SecuAAS développe Scanyze (EASM), ConformVault (transfert sécurisé), et une suite complète d'outils de cybersécurité pour PME — le tout hébergé 100% au Canada.