Lifecycle stage — Build
L'IA qui tourne à l'intérieur d'un système physique est un problème d'ingénierie différent de l'IA qui tourne dans le cloud. Un modèle déployé sur un PLC en ligne de production, un ECU dans un véhicule ou un nœud de calcul dans une sous-station doit tenir des SLA temps réel, survivre aux partitions réseau, respecter des enveloppes de sûreté que vos ingénieurs de certification examineront, et tourner sur du matériel dont le coût doit passer la comptabilité de l'exploitation. Les cabinets de conseil IA généralistes cloud ne savent pas faire ce travail — les architectures de référence ne s'appliquent pas et les équipes n'ont jamais rencontré un ingénieur sûreté. Il s'agit des phases PILOT et LAUNCH de la DEPLOY Method, adaptées aux systèmes physiques : une mission embarquée de 16 semaines qui mène un pilote IA edge de la découverte sûreté à la conception du modèle pour matériel contraint, à l'intégration avec la stack industrielle ou véhicule, puis au transfert opérationnel. Je suis Ambassadeur IA du Gouvernement Français pour la Transformation Numérique Finance & Entreprise — une désignation qui compte pour les travaux souverains et adjacents-défense — et j'ai mis huit ventures IA en production, y compris des travaux sur des systèmes autonomes. Le livrable est un déploiement que votre équipe d'exploitation fera tourner, pas une démo que votre équipe data abandonnera.
Votre plateforme data cloud-first n'a jamais été conçue pour pousser un modèle vers un PLC, un ECU véhicule ou un nœud de calcul de sous-station — et la reprendre est un projet à lui seul de trois trimestres. La stack MLOps que votre équipe a construite suppose une inférence cloud élastique, une connectivité réseau et du matériel surdimensionné. Aucune de ces hypothèses ne tient à la périphérie. Le modèle que votre équipe data a entraîné tourne sur du matériel que votre équipe d'exploitation contrôle, avec des contraintes que votre pipeline MLOps ne sait pas exprimer. La reprise devient un programme en soi, et elle mange le planning que le projet IA initial était censé livrer.
Les ingénieurs sûreté et certification ont un droit de veto et vous n'avez aucun processus qui produise les preuves dont ils ont besoin. Le modèle fonctionne en simulation. Votre ingénieur sûreté demande l'analyse des dangers, la couverture des modes de défaillance, les tests de violation d'enveloppe et la chaîne de preuves qui survivra à une revue de certification — et votre équipe data n'a jamais produit aucun de ces artefacts. Le projet s'enlise dans une revue dont votre équipe data ignorait l'existence jusqu'à la semaine dix. Personne n'a tort ; le transfert entre ingénierie ML et ingénierie sûreté n'a jamais été conçu dans votre entreprise parce que vous n'avez jamais mis d'IA dans un système physique régulé.
Votre équipe IA et votre équipe d'exploitation parlent des langues différentes, et leurs systèmes de tickets ne communiquent pas. Les data scientists parlent en scores F1, ensembles de validation et model cards. Les ingénieurs d'exploitation parlent en OEE, MTBF, cycles de scan PLC et timing des bus véhicule. Les deux groupes se rencontrent en comité de pilotage trimestriel et repartent sans accord concret. Sans langage partagé ni rythme opérationnel partagé, le modèle que votre équipe a livré n'est jamais accepté par l'équipe d'exploitation qui doit le faire tourner. Le projet n'échoue pas techniquement ; il échoue socialement.
Le modèle fonctionne en test de paillasse et s'effondre dès qu'il rencontre un vrai capteur avec la mauvaise dérive de calibration. Les données d'entraînement étaient propres. Les données de validation étaient propres. Le capteur en production a un biais thermique que personne n'a modélisé, une version de firmware dont votre équipe ignorait l'existence et une panne électrique intermittente que l'équipe d'exploitation tolère depuis six ans. La précision du modèle s'effondre au jour trois du pilote et personne ne peut dire si c'est le modèle qui est cassé, le capteur qui est cassé ou l'intégration qui est cassée. Cette ambiguïté est là où les projets IA edge vont mourir.
La mission se déroule en quatre phases de quatre semaines. Je travaille sur site lors des première et dernière phases et en embarqué à distance entre les deux. Vos équipes d'ingénierie, de sûreté et d'exploitation ont toutes du temps affecté — ce n'est pas un livrable qu'une équipe data peut porter seule. Le résultat est un déploiement tournant sur le matériel de production, sous le régime de sûreté, intégré à la stack opérationnelle.
Sessions structurées avec l'équipe d'ingénierie sûreté, le responsable certification, les ingénieurs d'exploitation qui feront tourner le système, et l'équipe ML qui a construit le pilote. Nous documentons l'enveloppe de sûreté, les modes de défaillance qui comptent, les artefacts de certification requis, les contraintes matérielles (calcul, mémoire, thermique, énergie), la topologie réseau et le comportement en partition, et les SLA opérationnels que le modèle doit tenir. À la fin de la semaine quatre, nous avons un document de contraintes écrit que l'ingénieur sûreté signera et contre lequel l'équipe ML pourra construire. C'est la phase que la plupart des projets sautent ; la sauter, c'est pourquoi la plupart des projets échouent.
L'architecture du modèle et la recette d'entraînement sont reconçues pour le matériel et l'enveloppe de sûreté. Stratégie de quantization, budget de latence, empreinte mémoire, comportement déterministe là où la sûreté l'exige, dégradation gracieuse en cas de panne capteur. Nous lançons les ablations sur matériel réel, pas en simulation. Nous construisons aussi la chaîne de preuves — analyse des dangers, couverture des modes de défaillance, tests de violation d'enveloppe — que la revue de certification exigera. Le modèle produit dans cette phase est celui qui sera déployé ; nous ne ré-architecturons pas après que les preuves de certification sont construites.
Le modèle s'intègre à la stack industrielle ou véhicule sur matériel réel — environnement de programmation PLC, réseau OT, bus véhicule, SCADA ou automatisme de sous-station. Le système de tickets de l'équipe d'exploitation reçoit les alertes que le modèle produira. Le chemin de mise à jour firmware, le mécanisme de rollback du modèle et le pipeline de déploiement over-the-air (ou over-the-wire) sont construits et testés. À la fin de la semaine douze, le modèle tourne sur matériel de production dans une zone pilote contrôlée — une ligne de production, un véhicule, une sous-station — sous le régime de sûreté et supervisé par l'équipe d'exploitation.
L'équipe d'exploitation s'approprie le déploiement. Nous construisons les runbooks qu'ils utiliseront, les seuils d'alerte qui correspondent à leur rythme opérationnel existant, les tableaux de bord de performance du modèle qu'ils peuvent lire sans formation ML, et les playbooks de rollback pour quand une mise à jour firmware se passe mal à 2 h du matin. Nous étendons la zone pilote à l'empreinte de production convenue en semaine un — ligne par ligne, véhicule par véhicule, site par site — avec l'ingénieur sûreté qui valide chaque extension. À mon départ, l'équipe d'exploitation fait tourner le système. L'équipe ML est consultée sur les mises à jour de modèle, pas sur les opérations quotidiennes.
Industriels, constructeurs automobiles, gestionnaires d'énergie et organismes publics avec un projet IA pilote à la périphérie — dans une usine, un véhicule, une sous-station ou un site d'infrastructure souveraine. Organisations où le responsable de l'ingénierie sait déjà que l'écart entre l'IA cloud et l'IA physique est réel, dispose d'un régime de certification et de sûreté que le projet doit franchir, et a besoin d'une voix extérieure ayant déjà mis de l'IA dans des systèmes physiques. Programmes d'infrastructure souveraine qui nécessitent un partenaire accrédité Ambassadeur IA pour des travaux adjacents-défense ou d'industries stratégiques. Ce n'est pas pour des éditeurs purs software — ils ont besoin du service Agentic System Engineering. Ce n'est pas non plus pour des organisations sans pilote déjà en cours ; la mission suppose un modèle existant et une équipe d'exploitation à qui le transférer.
À côté d'eux, avec des frontières de périmètre claires. Votre partenaire automatisation est propriétaire de l'environnement de programmation PLC, du réseau OT et de la couche d'intégration opérationnelle — c'est leur compétence cœur et je ne tenterai pas d'étendre mon périmètre à la leur. Je suis propriétaire de l'architecture du modèle, du déploiement de l'inférence edge, de la chaîne de preuves de certification et du processus de sûreté. Nous nous voyons chaque semaine pendant la mission pour que les livrables se réconcilient. Je l'ai fait aux côtés de grands intégrateurs industriels et la frontière fonctionne proprement quand les deux côtés la respectent.
Oui — et doit souvent le faire. Un modèle tournant sur un ECU véhicule, une sous-station distante ou une zone d'usine avec connectivité intermittente doit fonctionner pendant les partitions réseau et synchroniser son état au retour du lien. L'architecture gère cela explicitement : inférence on-device, gestion d'état local, résolution de conflits quand la télémétrie atteint la plateforme centrale, et dégradation gracieuse quand un service dépendant est injoignable. La conception est nourrie par ce que j'ai construit sur Auralink, où les agents doivent continuer à fonctionner quand une dépendance tombe.
Cela dépend du régime. La mission produit la chaîne de preuves de certification — analyse des dangers, couverture des modes de défaillance, tests de violation d'enveloppe — qui se mappe au standard sur lequel travaille votre ingénieur sûreté. Je ne suis pas un organisme de certification et je ne remplace pas votre ingénieur sûreté ; je construis les preuves dans la structure dont il a besoin pour que la revue ne s'enlise pas. Pour les classifications à haut risque de l'EU AI Act spécifiquement, la chaîne de preuves est explicitement conçue contre les exigences de l'Annexe III parce que c'est là qu'atterrissent typiquement les déploiements industriels et à système autonome.
Celui que votre équipe d'exploitation va approuver. En semaine un, nous identifions l'enveloppe matérielle réaliste — ce que les achats vont acheter, ce que l'exploitation va installer, ce que la maintenance va servicer. J'ai travaillé sur Jetson, Intel, AMD et silicium custom. La conception du modèle est nourrie par les contraintes matérielles, pas l'inverse ; je n'arrive pas avec une plateforme préférée parce que le bon matériel est celui que votre équipe d'exploitation fera effectivement tourner pendant les dix prochaines années.
Pas de manière significative. Les quatre phases représentent chacune une discipline différente — sûreté, ingénierie ML, intégration industrielle, exploitation — et chacune a besoin du temps qu'il lui faut. Compresser la phase sûreté produit un déploiement qui échoue à la certification. Compresser la phase d'intégration produit un déploiement que l'équipe d'exploitation rejette. Le seul endroit où je peux parfois gagner du temps est quand un partenaire existant en automatisation industrielle a déjà réalisé un travail d'intégration important ; la mission se concentre alors sur les couches modèle et sûreté et la phase d'intégration se compresse à deux semaines. Je vous le dirai en semaine un si c'est le cas.
Decouvrez d'autres services qui completent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.