L'ingénierie de l'IA,
sur un socle qui livre.

Le logiciel et le mobile sont la plus vaste discipline chez SDEN. Le travail couvre toute la surface : plateformes web (SaaS B2B, outillage interne, produits grand public), applications natives iOS et Android, mobile multiplateforme (Flutter, React Native), et les services dorsaux qui les soutiennent. Nous menons les projets de la page blanche jusqu'à l'architecture, le prototype, la mise en production progressive et l'exploitation après lancement — et nous reprenons aussi des bases de code qui ont stagné et doivent être refaites sans perdre la logique d'affaires déjà encodée.

Nos choix d'architecture par défaut sont délibérément ennuyeux. Next.js avec TypeScript et React pour la couche web ; PostgreSQL avec Prisma ou Drizzle pour la couche de données ; Node.js pour la surface d'API à moins qu'un domaine (temps réel, inférence d'AA, embarqué) n'exige autre chose. Le mobile penche vers Flutter ou React Native à moins que le produit n'exige une intégration profonde à la plateforme, auquel cas nous livrons du Swift ou du Kotlin natif. Le principe partagé : choisir l'outil que l'équipe pourra encore entretenir dans trois ans, pas le cadriciel qui était à la mode le trimestre dernier.

Le travail de sécurité chez SDEN prend trois formes. D'abord, la sécurité appliquée à l'intérieur d'une livraison — modélisation des menaces à la conception, analyse des dépendances en CI, détection de secrets, protection des branches, versions signées, architecture sécurisée par défaut. Ensuite, des mandats autonomes : audits, tests d'intrusion encadrés selon le OWASP Top 10 et les niveaux du OWASP ASVS, feuilles de route de correction et réponse aux incidents. Enfin, le travail de conformité : posture SOC 2, CCPA/CPRA et PIPEDA, état de préparation ISO 27001, état de préparation SOC 2, et la documentation que les acheteurs réclament avant de signer.

Un audit de SDEN produit trois artéfacts que vous pouvez remettre à votre conseil : un registre des risques classé par exploitabilité et impact d'affaires, 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 documentés avec des preuves de concept reproductibles — jamais un PDF qui évoque vaguement un constat.

La plupart des PDG et des fondateurs que nous rencontrons utilisent déjà l'IA — généralement trois ou quatre outils, souvent un flux ChatGPT maison, parfois un agent fournisseur que personne n'a audité. La question est rarement de savoir s'il faut utiliser l'IA. C'est plutôt de savoir laquelle de ces intégrations est porteuse, laquelle érode la confiance, et ce qui devrait plutôt être bâti à l'interne. Les mandats d'IA de SDEN prennent trois formes. D'abord, un audit d'IA : un inventaire de chaque intégration d'IA dans l'entreprise, les données qu'elle touche, sa place dans les chemins critiques, et un carnet de correction classé avec un verdict bâtir-ou-acheter pour chaque élément. Ensuite, des flux d'IA personnalisés : conçus en fonction d'un résultat mesurable, livrés avec un harnais d'évaluation, dont le client est propriétaire. Enfin, l'ingénierie d'IA intégrée, où SDEN s'installe au sein d'une équipe existante comme responsable de discipline jusqu'à ce que l'équipe puisse porter le travail elle-même.

La partie difficile de la livraison d'IA n'est pas de choisir un modèle. C'est de décider quoi mesurer, de bâtir le harnais d'évaluation qui le mesure, et de garder une boucle de rétroaction en direct une fois le produit en production. Nous commençons chaque mandat d'IA par la question à laquelle le modèle est censé répondre pour l'utilisateur — et nous refusons d'écrire du code avant de nous être entendus sur la façon dont nous saurons si la réponse est bonne. À partir de là, nous choisissons l'architecture la plus simple qui atteint le seuil : un modèle hébergé bien instruit là où ça fonctionne, la génération augmentée par récupération (RAG) sur vos données là où les réponses dépendent de contenu privé, et le réglage fin uniquement lorsque l'ingénierie d'invite et le RAG ont atteint un plafond.

La préparation à la production des fonctionnalités d'IA chez SDEN signifie un budget de latence documenté, un plafond de coût par requête, des garde-fous déterministes sur les entrées et les sorties (caviardage des RP, détection de contournement, taxonomie des refus), et un pipeline d'évaluation journalisé qui s'exécute contre un jeu réservé chaque fois que l'invite ou le modèle change. Les modèles sont des commodités ; la discipline d'évaluation, c'est le rempart.

L'infonuagique chez SDEN est multi-infonuagique par formation et flexible par région par défaut. Nous déployons sur AWS, GCP et Azure là où la charge de travail l'exige, et nous déployons dans votre région (États-Unis, Canada ou UE) lorsque le modèle de menaces et les exigences de résidence des données font d'une juridiction précise le meilleur choix. Dans tous les cas, l'infrastructure est livrée sous forme de code (Terraform, Pulumi ou l'IaC native du fournisseur), révisée dans le même flux de demandes de tirage que le code applicatif.

La discipline de coût n'est pas optionnelle. Chaque nouvelle fonctionnalité est livrée avec une estimation publiée en $/mois avant son déploiement, et nous menons une revue de coûts mensuelle contre la facture du mois précédent. Le constat le plus fréquent, ce sont les environnements de développement surdimensionnés — et le deuxième plus fréquent, les instantanés oubliés. Le coût n'est pas une préoccupation financière en aval de l'ingénierie ; c'est un livrable d'ingénierie dont nous nous portons garants.

Le travail de données chez SDEN commence en amont de l'entrepôt — au schéma. Nous modélisons les événements avec le même soin que les données applicatives : des contrats explicites, des schémas versionnés, et un rejet à la frontière lorsque la donnée ne correspond pas. Le pipeline fait ensuite atterrir les événements dans un entrepôt (PostgreSQL, BigQuery ou Snowflake selon le volume), où dbt devient la couche de transformation canonique et où les métriques sont calculées contre un modèle documenté, et non contre du SQL improvisé collé dans un tableau de bord.

Les livrables d'analytique sont des tableaux de bord qui survivent à l'ingénieur qui les a bâtis. Chaque graphique possède une lignée de données documentée, une garantie de fraîcheur, et un comportement défini lorsque la donnée en amont est en retard ou manquante. L'équipe peut répondre à « d'où vient ce chiffre ? » sans ouvrir cinq outils.

Le design chez SDEN n'est pas une couche peinte par-dessus l'ingénierie — il est à l'intérieur de celle-ci. Le même ingénieur qui cadre le modèle de données est dans la salle quand les maquettes filaires sont révisées, et la même designer qui mène la recherche utilisateur observe l'équipe d'ingénierie intégrer la rétroaction. Le résultat, c'est un produit dont l'interface et l'architecture ont été décidées ensemble, plutôt qu'agrafées l'une à l'autre après coup.

L'accessibilité est un défaut, pas une fonctionnalité. Nous livrons en WCAG 2.2 AA sur chaque produit à moins que le client ne choisisse explicitement un seuil inférieur — et nous testons contre les technologies d'assistance avant de déclarer une version. Les jetons de design (couleur, échelle typographique, espacement, mouvement) vivent dans une source unique de vérité, exportés vers Tailwind pour l'ingénierie et vers les bibliothèques Figma pour le design — pour que le système reste synchronisé sans réconciliation manuelle.

Le travail DevOps chez SDEN vise un résultat précis : un déploiement en une seule commande auquel toute l'équipe fait confiance. Le chemin vers ce résultat est sans éclat — protection des branches, revue de code obligatoire, tests automatisés qui conditionnent la fusion, infrastructure comme code, déploiements déclenchés depuis main, observabilité branchée avant la livraison de la fonctionnalité. Rien de tout cela n'est intéressant isolément. L'effet composé, c'est que les versions cessent d'être des événements pour devenir un rythme par défaut.

L'observabilité est traitée comme une fonctionnalité, pas comme une réflexion après coup. Chaque service émet par défaut des journaux structurés, des métriques RED (taux, erreurs, durée) et des traces. Les tableaux de bord sont versés dans le dépôt (Grafana comme code) pour qu'ils survivent à l'ingénieur qui les a bâtis, et les SLO sont mis par écrit pour que l'ingénieur de garde sache à quoi ressemble un véritable incident par rapport à une alerte bruyante.

L'IdO chez SDEN couvre toute la verticale : le micrologiciel sur l'appareil (C, C++, Rust, Python embarqué là où c'est approprié), le logiciel de passerelle à la périphérie, l'approvisionnement sécurisé de nouveaux appareils dans une flotte, et le dorsal infonuagique qui ingère la télémétrie et pousse les mises à jour. Nous travaillons dans des contextes réglementés et non réglementés et traitons la sécurité des appareils comme une préoccupation de premier ordre — clés approvisionnées par appareil, mises à jour de micrologiciel signées, et un parcours de divulgation documenté pour les vulnérabilités trouvées sur le terrain.

L'exploitation de flotte, c'est là que la plupart des projets d'IdO stagnent. Nous la concevons dès le premier jour : chaque appareil est identifié de manière unique, chaque image de micrologiciel est signée et traçable, chaque mise à jour à distance est progressive et réversible, et chaque interruption de connectivité dégrade vers un comportement hors ligne prévisible — pas vers une brique.