L'approche d'ingénierie
de SDEN.

Le cadrage chez SDEN n'est pas un appel de découverte. C'est une investigation structurée qui produit trois artéfacts : un énoncé de problème écrit qui nomme la véritable tâche que le logiciel doit accomplir, un diagramme d'architecture et un journal de décisions qui expliquent les choix techniques que nous recommandons (et les solutions de rechange que nous avons envisagées), et un registre des risques qui classe ce qui pourrait mal tourner selon l'exploitabilité et l'impact d'affaires. La phase se termine par une recommandation aller / ne pas aller que nous sommes prêts à défendre devant votre conseil.

Nous posons les questions que les autres fournisseurs sautent. Qui est le décideur imputable de votre côté ? À quoi ressemble le travail pour l'utilisateur le lendemain du lancement — et non pendant la démo ? Quelles données le produit crée-t-il, où sont-elles stockées et qui a le droit de les voir ? Quelle est la plus petite version de ce produit qui pourrait être mise en ligne, et quel est le seuil pour déclarer qu'elle est « en ligne » ? La phase est payée, encadrée dans le temps et courte — généralement d'une à trois semaines selon la portée.

Une démo, c'est une vidéo. Un prototype, c'est quelque chose que l'utilisateur peut réellement utiliser, sur la véritable forme des données, sur la pile exacte que nous livrerons en production. La deuxième phase livre ce dernier. L'équipe conçoit les parcours utilisateurs essentiels, bâtit un prototype interactif pour les chemins les plus à risque (ceux qui déterminent si le produit est utilisable, pas ceux qui déterminent s'il est joli), et les valide auprès de vrais utilisateurs avant qu'une seule ligne de code de production ne soit posée.

Les choix technologiques sont faits et documentés dans cette phase. Nous penchons vers la technologie ennuyeuse — des cadriciels, des bases de données et des hébergeurs que la communauté d'ingénierie a déjà déboguées à grande échelle — et nous nommons la raison de chaque choix. La phase produit un système de design (jetons, composants, base de référence d'accessibilité), le prototype interactif, et un plan de test écrit pour la phase de production qui énumère ce que nous mesurerons, automatiquement, avant la mise en ligne.

Le développement chez SDEN se déroule en itérations de deux semaines, avec une version fonctionnelle à la fin de chacune. Chaque demande de tirage est revue par un deuxième ingénieur avant la fusion ; la barrière de fusion exécute la suite de tests, les analyseurs de sécurité (SCA, SAST, détection de secrets) et le vérificateur de types. La protection des branches est activée, les validations signées sont activées, et aucun ingénieur — même le plus chevronné — ne peut contourner les vérifications. Le résultat est une base de code où le deuxième ingénieur à lire un fichier le comprend déjà.

Le durcissement est la partie que la plupart des fournisseurs sautent. C'est le travail qui transforme « ça roule » en « ça roule en production pour les trois prochaines années ». Cela inclut les tests de charge contre les profils de trafic attendus, les tests de chaos sur les modes de défaillance que le registre des risques a signalés à la première phase, la revue de sécurité contre le OWASP Top 10 et le niveau ASVS pertinent, ainsi que la clause d'absence de dette technique : nous ne livrerons pas de code pour lequel nous ne serions pas prêts à recevoir une alerte à 3 h du matin. Si une échéance force un raccourci, le raccourci atterrit dans le suivi des problèmes comme un P0 — et il est remboursé avant que la prochaine fonctionnalité n'arrive. Nous documentons explicitement cette discipline dans notre posture d'ingénierie de la sécurité.

La livraison est progressive. La première mise en production atterrit derrière un drapeau de fonctionnalité, pour un seul locataire ou une petite cohorte d'utilisateurs. Nous surveillons les SLO contre le trafic de production pendant une fenêtre d'observation définie, puis nous élargissons à l'auditoire complet une fois que les données confirment que le système se comporte comme prévu. La mise en production n'est pas un événement de calendrier — c'est un changement d'état mesurable.

Ce que nous remettons avec la version, c'est ce qui rend le mandat durable : un guide d'exploitation pour chaque tâche opérationnelle, un tableau de bord de surveillance qui expose les SLO que nous nous sommes engagés à respecter, un plan de garde pour les incidents que le registre des risques a anticipés, un gabarit de réponse aux incidents, et une documentation rédigée pour le prochain ingénieur qui se joindra à votre équipe. Les mandats SDEN ne se terminent pas à la mise en production — ils s'estompent. Nous nous engageons à une fenêtre de soutien définie après le lancement (habituellement de trois à six mois, calibrée au mandat) durant laquelle nous exploitons le système de production conjointement avec votre équipe, et durant laquelle le savoir opérationnel se transfère, pas seulement le code.