Comment nous travaillons,
pour chaque offre.

Le cadrage chez SDEN n'est pas un appel de découverte. C'est une investigation structurée qui produit un énoncé de problème écrit nommant la véritable tâche que le logiciel doit accomplir, une architecture et un journal de décisions expliquant 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. Pour le travail en IA, cela va plus loin : une lecture honnête de la faisabilité (est-ce un problème qu'un modèle peut résoudre de façon fiable, ou un moteur de règles déguisé en IA ?), un arbitrage bâtir-ou-acheter face aux solutions sur étagère, et un examen de la question de savoir si vos données sont réellement prêtes à alimenter un modèle. 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ù résident-elles et qui a le droit de les voir, et où se situent-elles dans les niveaux de risque du Règlement européen sur l'IA ? Surtout : que signifie « bon », mesuré ? Nous définissons les critères d'évaluation ici, en première phase, pour que « ça marche » soit un chiffre sur lequel nous nous sommes entendus plutôt qu'une impression à la démo. 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 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 sur de vraies données et auprès de vrais utilisateurs avant qu'une seule ligne de code de production ne soit posée.

Pour l'IA, c'est ici que se prennent et se consignent les choix lourds de conséquences : quel modèle, et pourquoi ; la recherche augmentée (RAG) plutôt que le réglage fin plutôt qu'une simple invite ; un seul appel plutôt qu'un agent ; et le budget de coût et de latence dans lequel chaque approche doit tenir. Nous penchons vers la technologie ennuyeuse sous l'IA (des cadriciels, des bases de données et de l'hébergement que la communauté a déjà déboguées à grande échelle) et nous nommons la raison de chaque choix. La phase conçoit aussi le banc d'évaluation : le jeu de tests noté qui nous dira, automatiquement et à chaque changement, si l'IA s'améliore ou se dégrade. Elle produit le prototype, un système de design (jetons, composants, base de référence d'accessibilité) et ce plan d'évaluation et de test pour la phase de production.

Le développement chez SDEN se déroule en itérations de deux semaines, avec une version fonctionnelle à la fin de chacune. Chaque pull request est revue par un deuxième ingénieur avant la fusion ; la barrière de fusion exécute la suite de tests, la suite d'évaluations de la deuxième phase, 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à, et où un changement qui dégrade discrètement l'IA fait échouer l'intégration continue au lieu d'atteindre la production.

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 ». Pour l'IA, cela signifie des garde-fous sur les entrées et les sorties, des plafonds de coût pour qu'une boucle emballée ne puisse pas ruiner la fonctionnalité, et une revue de sécurité contre l'injection d'invite et le OWASP LLM Top 10, en plus du OWASP Top 10 et du niveau ASVS pertinent. Cela inclut aussi 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, 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 (et, pour l'IA, les chiffres de qualité et de coût) contre du vrai 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 ainsi que le comportement de l'IA en production (qualité, dérive, taux d'hallucination et dépense, pas seulement la disponibilité), 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. Élément crucial, la remise transfère l'IA elle-même : les invites, la suite d'évaluations et les garde-fous, afin que votre équipe puisse modifier le système en toute sécurité, et pas seulement le maintenir en marche. 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 conjointement avec votre équipe, et durant laquelle le savoir opérationnel se transfère, pas seulement le code.