Lifecycle stage — Build
L'IA qui tourne dans un système physique est un problème d'ingénierie différent de l'IA qui tourne dans un cloud. Un modèle déployé sur un automate dans une ligne de production, un ECU dans un véhicule, un nœud de calcul dans un poste électrique ou un calculateur de vol dans un drone 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 par la comptabilité des opérations. Les cabinets de conseil générique en IA cloud ne peuvent 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é. Je suis Ambassadeur IA du Gouvernement Français pour la Transformation Numérique Finance & Entreprise — une désignation qui compte pour l'infrastructure souveraine et les industries stratégiques — et j'ai mis en production 10 ventures IA dont 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 de données cloud-first n'a jamais été conçue pour pousser un modèle vers un automate de cellule robotique, un ECU de véhicule, un contrôleur de flotte AGV ou un nœud de calcul de poste électrique — et la rétrofittation est à elle seule un projet de trois trimestres. Le stack MLOps que votre équipe a construit suppose une inférence cloud élastique, une connectivité réseau et du matériel que vous pouvez sur-provisionner.
Les ingénieurs sûreté et certification ont un droit de veto et vous n'avez aucun processus produisant les preuves dont ils ont besoin. Le modèle fonctionne en simulation. Votre ingénieur sûreté demande l'analyse de danger, 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 sous ISO 26262 (ASIL), IEC 61508 (SIL), DO-178C pour l'avionique drone, ou ISO 10218 pour la sécurité robotique.
Votre équipe IA et votre équipe d'exploitation parlent des langages différents, et leurs systèmes de tickets ne communiquent pas. Les data scientists parlent en scores F1, sets de validation et fiches modèle. Les ingénieurs d'exploitation parlent en OEE, MTBF, cycles de scrutation automate, timing bus véhicule et taux de conflits de chemin AGV.
Le modèle fonctionne à l'échelle du banc d'essai et s'effondre la première fois qu'il rencontre un vrai capteur avec la mauvaise dérive de calibration. La cellule robotique en production a un biais thermique que personne n'a modélisé, une version firmware que votre équipe ne connaissait pas, et un défaut encodeur intermittent que l'équipe maintenance tolère depuis trois ans.
L'engagement se déroule en quatre phases de quatre semaines. Je travaille sur site pour les première et dernière phases et à distance entre les deux. Vos équipes ingénierie, sûreté et exploitation ont toutes du temps assigné. Le résultat est un déploiement tournant sur le matériel de production, sous le régime de sûreté, intégré au stack opérationnel.
Sessions structurées avec l'équipe 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 (per ISO 26262 / IEC 61508 / DO-178C / ISO 10218 / Annexe III Règlement IA UE selon le cas), les contraintes matérielles, la topologie réseau et le comportement lors des partitions, et les SLA opérationnels que le modèle doit respecter. À la fin de la semaine quatre, nous avons un document de contraintes écrit que l'ingénieur sûreté signera et que l'équipe ML pourra utiliser comme base.
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 quantification, budget de latence, empreinte mémoire, comportement déterministe là où la sûreté l'exige, dégradation gracieuse lors de défaut capteur. Nous menons des ablations sur le vrai matériel — le contrôleur robotique cible, l'ECU véhicule, la carte de calcul AGV — pas en simulation. Nous construisons également la chaîne de preuves — analyse de danger, couverture modes de défaillance, tests de violation d'enveloppe — que la revue de certification exigera.
Le modèle s'intègre au stack industriel ou véhicule sur vrai matériel — environnement de programmation automate, réseau OT, bus CAN/Ethernet véhicule, système de gestion de flotte AGV, interface calculateur de vol UAS, ou relais d'automatisation de poste électrique. Le système de surveillance de l'équipe d'exploitation reçoit les alertes que le modèle produira. À la fin de la semaine douze, le modèle tourne sur le matériel de production dans une zone pilote contrôlée.
L'équipe d'exploitation possède le déploiement. Nous construisons les runbooks, les seuils d'alerte correspondant à 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. Nous étendons de la zone pilote au périmètre de production — cellule par cellule, AGV par AGV, véhicule par véhicule, site par site — avec la signature de l'ingénieur sûreté pour chaque extension.
Industriels déployant l'IA dans des cellules robotiques ou des flottes AGV/AMR. OEM automobiles et équipementiers intégrant l'IA dans des stacks ADAS ou AD sous ISO 26262 et UNECE R155/R156. Utilities énergie déployant de l'IA prédictive aux postes électriques ou en périphérie réseau sous IEC 62443. Maîtres d'œuvre aérospatiaux et défense intégrant l'IA dans des stacks d'autonomie UAS sous DO-178C ou cadres EASA. Ce service n'est pas pour les entreprises logicielles pures — celles-ci ont besoin du service Agentic System Engineering. Il n'est pas non plus pour les organisations sans pilote déjà en cours.
En parallèle, avec des limites de périmètre claires. Votre partenaire d'automatisation possède l'environnement de programmation automate, le réseau OT et la couche d'intégration opérationnelle. Je possède l'architecture du modèle, le déploiement d'inférence en périphérie, la chaîne de preuves de certification et le processus de sûreté.
L'engagement produit la chaîne de preuves de certification — analyse de danger, couverture modes de défaillance, tests de violation d'enveloppe — qui correspond à la norme sur laquelle travaille votre ingénieur sûreté. Je ne confonds pas les normes cyber (UNECE R155/R156) avec les normes de sécurité fonctionnelle (ISO 26262/IEC 61508) — elles régissent des domaines de défaillance différents et nécessitent des preuves différentes.
Oui — et souvent il le doit. Un modèle tournant sur un ECU de véhicule, un poste électrique distant, un AGV dans une zone d'entrepôt refusant le GPS, ou un UAS opérant au-delà de la portée radio doit fonctionner pendant les partitions réseau et synchroniser son état quand le lien revient.
Tout ce que votre équipe d'exploitation va approuver et maintenir pendant les dix prochaines années. En semaine un, nous identifions l'enveloppe matérielle réaliste — ce que les achats achèteront, ce que les opérations installeront, ce que la maintenance entretiendra.
Pas de façon significative. Les quatre phases représentent chacune une discipline différente — sûreté, ingénierie ML, intégration industrielle, opérations — et chacune a besoin du temps qu'il lui faut. L'endroit où je peux parfois gagner du temps est lorsqu'un partenaire d'automatisation existant a déjà effectué un travail d'intégration significatif.
Découvrez d'autres services qui complètent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.