L'ingénierie de l'IA,
sur un socle qui livre.
SDEN conçoit, sécurise, développe et vend l'IA en production — appuyé par huit disciplines d'ingénierie intégrées au sein d'une seule équipe chevronnée. L'IA est le sommet ; le logiciel, la sécurité, le cloud et les données sont le socle qui la rend prête pour la production, et non coordonnée d'un fournisseur à l'autre.
Survol
L'ingénierie de SDEN s'articule autour de l'IA comme discipline cœur, sur un socle de sept disciplines de soutien : développement logiciel et mobile, cybersécurité, gestion cloud, ingénierie des données et analytique, produit et design UX, DevOps et automatisation, ainsi que l'IdO et les systèmes embarqués. Chacune est dirigée par un ingénieur chevronné qui en est propriétaire de bout en bout sur chaque mandat.
Nous gardons l'IA et les disciplines qui la livrent au sein d'une seule petite équipe, et ce, délibérément. La plupart des fournisseurs répartissent les disciplines entre des entreprises distinctes — une boutique d'IA, une agence frontale, une firme-conseil en sécurité, un revendeur cloud — puis demandent au client d'en coordonner les coutures. C'est dans cette coordination que les projets d'IA échouent. Chez SDEN, les coutures sont à l'intérieur d'une seule équipe, avec une seule architecture, un seul jeu de conventions et un seul responsable imputable. L'inconvénient, c'est que nous travaillons avec un nombre limité de clients à la fois. L'avantage, c'est la qualité d'ingénierie que vous pouvez lire dans le code que nous livrons.
Ce qui suit, c'est ce que nous entendons — concrètement — par chaque domaine : le travail que nous prenons en charge, les choix techniques par défaut que nous apportons à chaque projet, les livrables auxquels vous pouvez vous attendre, et un anti-modèle que nous ne livrerons pas dans votre base de code.
SDEN audite les intégrations d'IA qu'une entreprise exploite déjà, conçoit les flux personnalisés qu'elle devrait exploiter ensuite, et les livre en production avec les harnais d'évaluation qui les gardent honnêtes — RAG, agents, classification, génération.
La plupart des fondateurs que nous rencontrons utilisent déjà l'IA — quelques outils, souvent un flux ChatGPT maison, parfois un agent fournisseur que personne n'a vérifié. La vraie question n'est pas de savoir s'il faut l'utiliser, mais laquelle de ces intégrations est porteuse, laquelle érode la confiance, et ce qui devrait être bâti à l'interne.
Nous y répondons de trois façons : un audit de chaque intégration, des flux personnalisés conçus en fonction d'un résultat mesurable et dont vous êtes propriétaire, ou un ingénieur intégré qui mène la discipline jusqu'à ce que votre équipe puisse la porter.
La partie difficile n'est jamais le modèle — c'est de décider quoi mesurer et de garder la boucle honnête en production. Nous fixons la mesure de succès d'abord, puis prenons la chose la plus simple qui atteint le seuil : un modèle hébergé bien instruit, le RAG sur vos données quand les réponses dépendent de contenu privé, et le réglage fin seulement quand les deux ont plafonné.
Les modèles sont des commodités. L'évaluation, c'est le rempart.
Defaults we ship
- Audit d'intégration d'IA avec un carnet de correction découpé en problèmes livrables
- OpenAI, Anthropic Claude et modèles à poids ouverts selon le coût, la latence et la confidentialité
- RAG avec récupération hybride (sémantique + lexicale) et citation explicite
- Harnais d'évaluation hors ligne + test A/B en ligne avant toute mise en production d'un changement d'invite ou de modèle
- Caviardage des RP et garde-fous contre l'injection d'invite à la frontière
Deliverables
- Rapport d'audit d'IA : inventaire, registre des risques (OWASP LLM Top 10 + exposition des données) et carnet de correction classé
- Définition du cas d'usage avec des critères de succès mesurables
- Harnais d'évaluation versé dans votre dépôt avec un jeu de données de référence
- Environnement d'exécution en production avec tableaux de bord de latence, de coût et de qualité
- Garde-fous : validation des entrées, filtrage des sorties, gestion des refus
Ce que nous refusons de livrer
Nous ne livrerons pas une fonctionnalité d'IA sans harnais d'évaluation. Les démos qui marchent entre les mains des fondateurs et plantent en production, c'est ainsi que les projets d'IA perdent leur budget.
SDEN conçoit et livre des plateformes web de production, des applications SaaS, ainsi que des applications mobiles natives et multiplateformes — de la page blanche jusqu'à l'App Store, au Play Store et à la production en direct.
Notre plus grande pratique : plateformes web, applications natives iOS et Android, mobile multiplateforme (Flutter, React Native) et les services dorsaux qui les soutiennent.
Nous menons un produit de la page blanche jusqu'à la mise en production — ou reprenons une base de code qui a stagné et la refaisons sans perdre la logique déjà encodée.
La pile est délibérément ennuyeuse : Next.js, TypeScript et React sur le web, PostgreSQL pour les données, Node sur l'API, et du Swift ou du Kotlin natif seulement là où le produit le justifie. La règle : choisir ce que votre équipe pourra encore entretenir dans trois ans — pas ce qui était à la mode le trimestre dernier.
Defaults we ship
- TypeScript de bout en bout (aucune frontière non typée entre le serveur et le client)
- Interface pilotée par composants avec un système de design partagé
- Rendu côté serveur par défaut ; rendu côté client uniquement là où l'interactivité l'exige
- Publications sur l'App Store et le Play Store automatisées par l'intégration continue
Deliverables
- Enregistrement de décision d'architecture (ADR) pour chaque choix non trivial
- Contrat d'API typé de bout en bout entre le frontal et le dorsal
- Pipeline CI/CD qui bâtit, teste et déploie à chaque validation
- Documentation rédigée pour le prochain ingénieur, pas pour le chef de projet
Ce que nous refusons de livrer
Nous ne transmettrons pas une pile que le client ne peut pas entretenir après notre départ. Si l'équipe qui hérite du code se résume à deux généralistes chevronnés, nous livrons une infrastructure ennuyeuse — et non un maillage de microservices polyglotte.
SDEN traite la cybersécurité comme une discipline d'ingénierie appliquée à chaque ligne de code — de la modélisation des menaces à l'étape de conception jusqu'à la surveillance continue une fois le produit en ligne.
La sécurité se présente de trois façons. Intégrée à une livraison — modélisation des menaces, analyse des dépendances et des secrets, protection des branches, versions signées. Comme mandat autonome — audits, tests d'intrusion encadrés selon le OWASP Top 10 et l'ASVS, feuilles de route de correction, réponse aux incidents. Ou guidée par la conformité — SOC 2, RGPD, préparation ISO 27001.
Un audit vous laisse trois choses à mettre devant un conseil : un registre des risques classé par exploitabilité, un carnet de correction découpé en billets livrables, et une configuration CI durcie qui empêche la même classe de bogues de revenir.
Les tests d'intrusion sont livrés avec des preuves reproductibles — jamais un PDF qui évoque vaguement un constat.
Defaults we ship
- Modélisation des menaces à l'étape de conception, et non après le lancement
- OWASP Top 10 + OWASP ASVS niveau 2 comme seuil minimal pour les produits livrés
- Analyse des dépendances (SCA), SAST et détection de secrets imposés en CI
- Journaux d'audit conservés au minimum 12 mois
Deliverables
- Registre des risques avec gravité, exploitabilité et impact d'affaires
- Carnet de correction découpé en problèmes livrables
- Configuration CI durcie (SCA, SAST, détection de secrets) versée dans votre dépôt
- Rapport de retest une fois les correctifs livrés
Ce que nous refusons de livrer
Nous ne livrerons pas un audit de sécurité sous forme de PDF. Chaque constat atterrit dans votre suivi des problèmes comme un billet corrigeable assorti d'un reproducteur, et nous retestons ce qui a été corrigé avant de le fermer.
SDEN bâtit les pipelines de données, les entrepôts et les couches d'analytique qui transforment des événements produit bruts en métriques que les équipes peuvent défendre en réunion de conseil.
Le travail de données commence en amont de l'entrepôt, au schéma. Les événements sont modélisés avec la même rigueur que les données applicatives — contrats explicites, schémas versionnés, rejetés à la porte lorsqu'ils ne correspondent pas.
De là, ils atterrissent dans PostgreSQL, BigQuery ou Snowflake selon le volume, avec dbt comme unique couche de transformation et des métriques calculées contre un modèle documenté — pas contre du SQL improvisé collé dans un graphique.
Les tableaux de bord que nous laissons derrière survivent à qui les a bâtis : lignée documentée, garantie de fraîcheur, et comportement défini lorsque la donnée en amont tarde ou manque. N'importe qui peut répondre à « d'où vient ce chiffre ? » sans ouvrir cinq outils.
Defaults we ship
- Schéma à l'écriture avec des contrats de données explicites à l'ingestion
- dbt comme couche de transformation canonique ; le SQL est révisé comme du code
- Choix d'entrepôt fondé sur le volume, et non sur le fournisseur le plus bruyant
- Tableaux de bord avec lignée documentée et SLA de fraîcheur
Deliverables
- Définitions de schéma d'événements versées dans le dépôt applicatif
- Projet dbt avec des modèles et des tests documentés
- Tableaux de bord d'analytique (Metabase, Looker ou votre outil de BI existant)
- Surveillance de la qualité des données avec alertes sur la fraîcheur et les anomalies de nombre de lignes
Ce que nous refusons de livrer
Nous ne livrerons pas un tableau de bord que personne ne peut expliquer. Les métriques qui ne peuvent être retracées jusqu'à un événement source sont rejetées, pas approximées.
