Références

Valider d'abord : une résidence multi-sites Hyper-V & SCVMM

Pour le client final d'un prestataire mondial de services IT — l'administration d'un État américain · livrée dans le cadre d'un contrat de résidence Dell

Les ingénieurs du client avaient déjà fait le plus dur : hôtes déployés, clusters de basculement constitués, fabric réseau construite entre deux sites. Ce qu'ils demandaient n'était pas une reconstruction — c'était une certitude. Était-ce bien construit ? Est-ce que cela tiendrait en exploitation ? Et à quoi devait ressembler la couche de management ?

Nous avons structuré la résidence autour de cette question. Les trois premières semaines ont été de la validation pure : configuration des hôtes, comportement des clusters, chemins de stockage et chemins réseau — testés méthodiquement, avec des constats documentés au fil de l'eau. Pas d'hypothèses héritées, pas de crédit accordé au « ça devrait aller ».

Sur cette fondation validée, nous avons conçu l'état cible SCVMM et l'avons déployé sur les deux sites, avant des sessions d'enablement pour que l'équipe du client exploite ce qui lui appartenait désormais.

Le moment pour lequel nous racontons cette histoire est arrivé à mi-parcours : l'équipe d'ingénierie du client a passé notre design d'état cible en revue et a contesté l'une de ses décisions centrales — où placer la frontière de responsabilité entre Network ATC et SCVMM pour la configuration réseau. Ils avaient raison d'insister. Nous avons révisé le design, et la version 1.1 porte la marque de leur revue : une répartition plus nette de qui gère quoi, validée ligne par ligne avec les personnes qui exploitent la plateforme.

Certains cabinets appelleraient cela une friction de périmètre. Nous y voyons la mission fonctionnant exactement comme prévu — nous concevons avec le client, pas contre lui. Un design qui résiste aux propres ingénieurs du client vaut plus qu'un design jamais contesté.

Ce qui est resté après notre départ : des rapports de validation, le design d'état cible révisé, la documentation de build, et une équipe rendue autonome dans l'exploitation de la plateforme. Chaque heure de la résidence a laissé un artefact.

Une méthodologie de migration d'applications, industrialisée

Mission de migration d'applications en cours avec Dell · delivery B2B2B

Les migrations d'applications échouent rarement à cause de l'outillage. Elles échouent dans les interstices — entre la discovery et la planification, entre le runbook dans la tête de quelqu'un et celui exécuté à deux heures du matin, entre « on peut revenir en arrière » et un plan de rollback réel et testé.

Dans notre mission avec Dell, nous avons pris la méthodologie de migration en trois phases de Dell et nous l'avons industrialisée : pas un framework sur slides, mais une usine de migration gouvernée.

Comment fonctionne l'usine :

• Des jalons de phase (phase gates). Chaque phase se termine par un jalon aux critères d'entrée et de sortie définis. Rien n'avance sur la seule inertie.
• Des runbooks générés — et des plans de rollback générés. Pour chaque move group, l'usine produit le chemin aller et le chemin retour, sous une forme cohérente et révisable. Le plan de rollback n'est pas une pièce rapportée ; il est généré en même temps que le runbook, à chaque fois.
• Un go/no-go humain. Les agents IA préparent les éléments de décision — synthèse de discovery, cartographie des dépendances, contrôles de validation, documentation. C'est un humain qui prend chaque décision de jalon. Aucune étape de migration ne s'exécute sur la seule parole d'un agent.
• Une traçabilité complète. Chaque décision et chaque action est journalisée et attribuable : quoi, quand, par qui, sur quelle approbation.

Nous sommes volontairement prudents sur ce que cette page affirme. C'est une histoire de méthodologie et de capacité : l'usine est productisée au sein d'une mission Dell active, livrée en B2B2B aux clients de Dell. Nous publierons des résultats quand des migrations clients seront terminées — pas avant.

Si votre backlog de migration ressemble à une longue série de projets héroïques menés une seule fois, le modèle d'usine est l'alternative : une constance industrielle dans les artefacts, un jugement humain à chaque jalon.

La delivery agentique, sous supervision d'ingénieurs

Notre modèle de delivery · comment se déroule chaque mission Gus IT

La première question qu'un acheteur sérieux pose sur la delivery pilotée par l'IA est la bonne : est-il sûr de laisser des agents IA s'approcher d'une infrastructure de production ?

Notre réponse est une division du travail stricte, appliquée à chaque mission.

Ce que font nos agents IA : l'ingénierie répétitive qui consume du temps senior et favorise l'erreur humaine. Ils mènent la discovery sur des parcs entiers, synthétisent les configurations en documentation, génèrent runbooks et plans de rollback, exécutent les contrôles de validation et tiennent le dossier à jour — avec constance, à toute heure, sans fatigue.

Ce qu'ils ne font jamais : approuver un design. Toucher un système de production sans supervision. Prendre une décision go/no-go.

Chaque mission a un ingénieur senior nommément désigné, qui assume l'approbation du design et chaque action modifiant l'état des systèmes. Notre automatisation est conçue pour le dry-run : elle peut être répétée sans toucher aux systèmes réels, et chaque phase porte un plan de rollback avant de porter un changement. Chaque action — humaine ou agentique — est journalisée et attribuable : vous savez toujours qui a décidé et qui a agi.

Pourquoi cela compte pour vous : vous obtenez la constance d'une usine dans les artefacts — une documentation réellement complète, des runbooks réellement à jour — sans abandonner le jugement à une machine. L'ingénieur ne corrige pas les devoirs de l'IA après coup ; l'ingénieur est le jalon par lequel le travail doit passer.

Ce n'est pas un concept de laboratoire. C'est ainsi que nous livrons aujourd'hui nos missions sous contrat, y compris dans le cadre de contrats partenaires et channel.

Si vous pesez la place de l'IA dans votre chaîne de delivery — ou la façon de la gouverner une fois en place —, apportez vos questions les plus dures au diagnostic. Ce modèle est fait pour être interrogé.