Ingénieur Cloud

1. Contexte

Le 1817 est la digital factory du groupe Vicat, présent dans 12 pays. Entité autonome dans son fonctionnement et ses méthodes, elle réunit trois conditions rarement présentes ensemble : la capacité d’innover et d’itérer vite, un terrain d’application immédiat et exigeant, et la solidité d’un groupe industriel international.

Nos sujets partent du terrain industriel : conduite et optimisation de procédés, maîtrise de la qualité, performance énergétique, maintenance, sécurité, supply chain. Les solutions que nous produisons ne sont pas des démonstrateurs : elles sont mises en service sur des sites de production, utilisées quotidiennement par les exploitants, et suivies dans la durée.

Ces solutions ne s’arrêtent pas aux frontières du groupe Vicat. Les produits et services que nous développons ont tous vocation à être proposés à des acteurs externes – plusieurs le sont déjà. Cette double destination change la manière de concevoir : ce que nous construisons doit être suffisamment robuste, générique et documenté pour fonctionner ailleurs que sur le site où il a été imaginé.

Le portefeuille de cas d’usage est en croissance rapide afin de couvrir l’ensemble des fonctions, de la conduite d’installation aux fonctions support. Cette croissance fait de la capacité à industrialiser, déployer et exploiter dans la durée un enjeu central : les sujets ne manquent pas, l’enjeu est d’en transformer le plus grand nombre en solutions réellement utilisées.

L’équipe réunit des chefs de projet, des responsables de déploiement, des data scientists, des développeurs et des ingénieurs plateforme, qui travaillent ensemble sur l’ensemble du cycle de vie de nos solutions.

2. Missions principales

a)    Concevoir, construire et opérer la plateforme sur laquelle tournent nos solutions, du cloud au datacenter interne jusqu’aux équipements de terrain : réseau, identités, secrets, environnements décrits en code, ressources de calcul – malgré la ségrégation des réseaux IT et OT.

b)    Rendre reproductible le déploiement d’une solution sur un nouveau site ou chez un nouveau client : orchestration élastique, briques d’infrastructure et standards réutilisables. L’objectif est qu’un nouveau déploiement relève du paramétrage, pas du projet.

c)     Industrialiser la mise en production des modèles : packaging, chaînes de déploiement, versioning et rollback, registry et lineage, automatisation du réentraînement – avec les garde-fous qu’impose un modèle qui agit sur un procédé réel.

d)    Exploiter dans la durée : niveaux de service tenus avec les sites, gestion des incidents, sécurité opérationnelle, sauvegarde et reprise, maîtrise de la capacité et des coûts. Ce qui tourne sur un site de production doit continuer à tourner.

e)    Mettre en place l’observabilité de bout en bout : infrastructure et applicatif, mais aussi dérive des données et des modèles, tenue du gain métier dans la durée et retour d’usage des exploitants.

f)     Outiller l’équipe et diffuser les pratiques : fournir aux data scientists et aux développeurs les chaînes, environnements et standards qui leur permettent de mettre en production de façon autonome – revues de code, veille technologique, partage de connaissances.

Ce que le poste n’est pas

Vous n’entraînez pas les modèles et ne concevez pas les algorithmes : c’est le métier des data scientists de l’équipe. En revanche, vous connaissez les outils du ML et les contraintes propres à un modèle en production – versions, données, dérive, non-déterminisme – parce que ce sont elles qui dictent la manière dont la plateforme est construite. À l’inverse, ce n’est pas non plus un poste d’infrastructure générique : vous connaissez les solutions que vous déployez, vous parlez à ceux qui les utilisent, et vous êtes co-responsable de leur bon fonctionnement.

3. Activités détaillées

Les éléments ci-dessous sont donnés à titre illustratif et non limitatif. Selon les projets, le poste mobilise tout ou partie de ces domaines ; il n’est pas attendu qu’un candidat les maîtrise tous.

3.1 Plateforme cloud et hybride

• Construction et exploitation du socle cloud : découpage des environnements, réseau (endpoints privés, peering), gestion des identités et des droits, secrets, chiffrement

• Arbitrage entre services managés et composants auto-hébergés, sous la contrainte de devoir également fonctionner en datacenter interne et sur site

• Connexions sécurisées entre cloud, datacenter interne et sites : enclaves, zones de transit, data diode ou passerelle applicative – conçues avec l’architecture groupe, mais opérées et adaptées à nos usages data de notre côté

• Fonctionnement en mode dégradé : réplication et cache local, files d’attente, reprise propre lorsque le lien tombe puis revient

• Infrastructure as Code : reproductibilité des environnements d’un site à l’autre, un déploiement sur une nouvelle usine devant être un paramétrage et non un projet

• Gestion des ressources de calcul : dimensionnement, mutualisation et ordonnancement des GPU et CPU d’entraînement (file d’attente, quotas par projet)

• Maîtrise des coûts : visibilité par projet et par usage, dimensionnement, recours aux instances préemptibles ou réservées pour les charges d’entraînement

• Interlocuteur technique des équipes IT groupe et des équipes automatisme / OT des sites sur les sujets réseau, sécurité et hébergement

3.2 Déploiement, orchestration et scalabilité

• Orchestration de type Kubernetes permettant d’ajouter des conteneurs au fil de l’augmentation du nombre d’équipements instrumentés sur un site, sans réarchitecturer

• Prise en compte des contraintes edge et OT : ressources limitées, connectivité non garantie, redémarrages, coexistence avec les systèmes de conduite

• Standardisation des composants de déploiement – charts, templates, paramétrage par site – pour que l’ouverture d’un nouveau site ou d’un nouveau client mobilise le minimum de spécifique

• Gestion de flotte : propager une mise à jour sur plusieurs sites de façon contrôlée, et savoir à tout moment dans quel état se trouve chacun d’eux

• Contribution aux déploiements chez des clients externes, avec les contraintes d’exploitation et de support associées

  3.3 Industrialisation des modèles en production

• Chaînes d’intégration et de déploiement dédiées au ML : tests automatisés sur les données et sur les modèles (conformité de schéma, plages de valeurs, performance minimale, non-régression), packaging, promotion entre environnements d’intégration et de production

• Versioning et gestion des rollbacks : savoir à tout moment quelle version tourne sur quel équipement, et pouvoir revenir en quelques minutes au modèle précédent sur un site donné

• Stratégies de déploiement progressif : shadow mode (le modèle tourne sans agir), canary sur un site pilote, A/B entre deux versions – indispensable sur les solutions d’optimisation temps réel (RTO) et de commande prédictive (MPC), où une mauvaise consigne a un coût procédé réel

• Registry unifié et lineage de bout en bout : modèles, jeux de données, features et images de conteneurs, avec la synchronisation on-premise ↔ cloud ; pour une prédiction donnée en production, pouvoir remonter au modèle, aux données d’entraînement, au code et aux hyperparamètres – prérequis pour le diagnostic comme pour l’audit interne et l’AI Act

• Automatisation du réentraînement : orchestration des déclencheurs (dérive, calendrier, nouvelle campagne de données), choix du lieu d’exécution (edge, datacenter, cloud) et chemin de retour du modèle réentraîné vers les systèmes de terrain, dans le respect de la ségrégation IT/OT. Le contenu du réentraînement reste la main des data scientists ; vous en construisez et en opérez la mécanique

• Suivi d’expérimentations mutualisé (MLflow ou équivalent) et cycle de vie des artefacts : hébergement, sauvegarde, droits d’accès, conventions de nommage, rétention, promotion entre états

3.4 Exploitation, fiabilité et sécurité

• Niveaux de service définis et tenus avec les sites : disponibilité, fraîcheur des prédictions, délai de rétablissement – et la discussion des arbitrages que cela implique

• Gestion des incidents : détection, qualification, escalade, communication vers les sites, puis post-mortems sans recherche de coupable et corrections effectivement mises en œuvre

• Runbooks et automatisation des gestes d’exploitation récurrents, avec l’objectif que la charge d’exploitation croisse moins vite que le nombre de sites

• Sauvegarde, restauration et reprise après incident : testées, pas seulement documentées

• Sécurité opérationnelle : vulnérabilités des images, application des correctifs, rotation des secrets, revue périodique des accès

• Gestion de la capacité et des coûts dans la durée, à mesure que le nombre de sites et de modèles en service augmente

4. Environnement de travail, conditions et avantages

Vos conditions de travail

• Contrat : CDI cadre, basé à Lyon 7e

• Télétravail : 2 jours flexibles par semaine, en journées complètes et/ou demi-journées

• Déplacements : ponctuels, en France et à l’international, sur les sites du groupe ou chez nos clients

• Rémunération : selon expérience

• Formation : accompagnement du développement des compétences, avec des formations proposées régulièrement

• Cohésion : événements d’équipe et culture privilégiant l’autonomie

Vos avantages

• Mutuelle Alan premium, 100 % digitale : téléconsultation 7j/7 et remboursements rapides

• Tickets restaurant de 10 €, pris en charge à 60 % par l’employeur

Environnement technique de l’équipe

Cloud (AWS) et environnements on-premise · conteneurisation (Docker) et orchestration (Kubernetes) · Infrastructure as Code (Terraform, Ansible ou équivalent) · chaînes CI/CD (GitLab CI, GitHub Actions ou équivalent) · déploiement continu (Helm, ArgoCD / Flux ou équivalent) · Linux · observabilité (Prometheus, Grafana, Loki ou équivalent) · Python · Git et pratiques de développement collaboratif · registry de modèles et suivi d’expérimentations (MLflow ou équivalent)

Formation et expérience

• Formation supérieure Bac+5 : école d’ingénieur ou master en informatique, systèmes distribués, infrastructure, data engineering ou data science

• Plus de 3 ans d’expérience en ingénierie de plateforme, cloud, DevOps, SRE et 3 ans en MLOps, dont une expérience significative de systèmes réellement exploités en production, avec ce que cela implique de mises à jour, d’incidents et de reprises

Compétences techniques indispensables

• Conception et exploitation d’une plateforme cloud : réseau, identités et droits, secrets, environnements, coûts

• Conteneurisation et orchestration : Docker, Kubernetes

• Automatisation et Infrastructure as Code

• Conception et exploitation de chaînes d’intégration et de déploiement continus

• Administration Linux, bases solides en réseau et en sécurité – suffisantes pour dialoguer avec les équipes IT et OT

• Mise en place d’une chaîne d’observabilité : métriques, journaux, alerting

• Pratique de l’exploitation : gestion d’incidents, astreinte ou permanence, post-mortems, sauvegarde et restauration

• Compréhension des contraintes propres aux systèmes ML en production : versioning conjoint du code, des données et des modèles ; dérive ; dépendance à la qualité des flux entrants ; validation qui ne se réduit pas à des tests unitaires. Il n’est pas attendu que vous entraîniez les modèles, mais que vous sachiez ce qui casse quand ils tournent

• Maîtrise de Python et des pratiques de développement logiciel : code testé, versionné, documenté, pensé pour être exploité par d’autres

• Anglais lu et parlé

Compétences techniques appréciées

• Pratique des outils MLOps : registry de modèles, suivi d’expérimentations, lineage, détection de dérive, automatisation du réentraînement

• Déploiement et exploitation en environnement contraint : edge, ressources limitées, connectivité intermittente

• Connaissance des environnements industriels et de la séparation des réseaux IT/OT

• Gestion de ressources de calcul mutualisées, notamment GPU

• Démarche FinOps sur des charges de calcul variables

• Culture data science suffisante pour comprendre ce que fait un modèle et dialoguer avec ceux qui le construisent

• Sensibilité aux exigences de conformité et d’audit (AI Act, audits internes)

Compétences comportementales

• Sens du service et de la plateforme : ce qui est construit est utilisé quotidiennement par d’autres ; sa qualité se mesure à l’autonomie qu’il leur donne

• Sens du concret : préférer une chaîne simple, comprise et réellement exploitée à une architecture élégante que personne ne sait opérer

• Fiabilité et sens des responsabilités : ce qui tourne sur un site de production ne s’arrête pas sans conséquence

• Calme en incident : savoir rétablir d’abord, comprendre ensuite, et documenter pour que cela ne recommence pas

• Culture produit : penser dès la conception à la réutilisation, ce qui est construit pour un site doit pouvoir servir ailleurs

• Curiosité pour le procédé industriel : envie de comprendre les contraintes d’exploitation, d’aller en salle de contrôle et d’écouter ceux qui conduisent l’installation

• Sens du collectif et pédagogie : rendre les autres autonomes plutôt que rester le passage obligé

• Autonomie et responsabilité : assumer ses développements jusqu’à leur exploitation en production

• Un entretien avec une personne du service technique

• Un entretien avec une personne de la direction