Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 21 octobre 2026.

En bref

Pour auditer une infrastructure IA, nous recommandons de relever les ressources et leurs risques, puis de comparer l’existant à une alternative construite et testée. La fiche de réalisation TW3 Partners, relevée le 9 octobre 2026 décrit un relevé par API de 153 ressources, sur un cloud partagé avec une vingtaine d’autres applications. Le poste GPU pesait l’essentiel de la facture. La cible construite chez Scaleway en France associe cluster Kubernetes, GPU L4, bases managées, vLLM et modèles ouverts ; elle a été testée de bout en bout avec les modèles d’embeddings. Selon l’Insee, le 21 juillet 2026, les résultats de l’enquête 2025 montrent que 73 % des entreprises utilisant l’IA recourent à des services payants de cloud computing, contre 33 % des autres. Le champ décrit dans la rubrique méthodologique de l’Insee couvre les entreprises implantées en France hors Mayotte, de 10 personnes occupées ou plus, des secteurs principalement marchands hors agriculture, finance et assurance.

1. Que couvre un audit d’infrastructure IA ?

Dans le périmètre que nous proposons, un audit d’infrastructure IA désigne l’inventaire des ressources qui font fonctionner une plateforme, l’examen de leurs risques et de leur coût, puis l’étude d’une alternative. Son périmètre porte sur les moyens techniques et leur exploitation ; l’audit de conformité d’un système d’IA relève d’un travail distinct.

Dans la réalisation publiée par TW3 Partners, la plateforme IA était déjà en production. Le problème associait un coût GPU élevé à une dépendance envers un socle non maîtrisé. La mission devait donc documenter l’existant tout en donnant au client une option de remplacement chiffrée.

Pour cadrer un audit comparable, nous recommandons de faire préciser par la DSI les applications concernées, les accès disponibles et les services qui doivent continuer à fonctionner pendant l’étude. Le commanditaire devrait aussi formuler la décision attendue : corriger la plateforme actuelle, étudier un autre hébergement ou préparer une migration. Cette formulation sert ensuite à définir les éléments à réunir pour arbitrer.

2. Pourquoi relever les ressources par API ?

Le relevé par API sert ici à établir l’inventaire ressource par ressource : la fiche TW3 Partners décrit 153 ressources et une étape de relevé et de cartographie. Le contexte est celui d’une plateforme partagée avec une vingtaine d’autres applications.

Notre recommandation est de conserver la date du relevé, son périmètre et les accès employés. Pour chaque ressource, demander son rattachement à une application et l’équipe qui en assume l’exploitation permet d’organiser la relecture avec le client. Lorsque ce rattachement reste à établir, il peut devenir une action explicite du rapport.

Nous proposons également de faire relire la cartographie par les équipes qui exploitent le socle commun. Elles peuvent être sollicitées pour confirmer les dépendances et identifier les validations nécessaires avant un changement.

3. Qu’est-ce qu’un rapport d’étonnement, et que doit-il contenir ?

Nous recommandons de traiter le rapport d’étonnement comme un document de constats : ce qui surprend lors de l’examen, les éléments qui l’établissent et les conséquences à examiner. La fiche TW3 Partners associe ce rapport au chiffrage ; son résumé identifie le poids du GPU dans la facture et les risques de l’infrastructure.

Pour chaque constat, notre grille de rédaction consiste à distinguer l’observation, la pièce qui la justifie et la question soumise au client. Une dépendance à éclaircir devrait ainsi donner lieu à une demande de vérification auprès de son responsable. Une proposition de changement devrait préciser le service concerné et la décision qu’elle appelle.

La revue du rapport peut ensuite servir à hiérarchiser les travaux avec la DSI et les achats cloud. Nous recommandons de conserver la trace des arbitrages : constat accepté, vérification complémentaire ou étude d’une alternative. Le chiffrage peut alors s’appuyer sur un périmètre validé par les personnes qui connaissent l’exploitation et les engagements contractuels.

4. Pourquoi construire et tester la plateforme cible ?

Construire et tester la cible donne au client une option concrète à examiner en regard de l’existant. Selon la fiche TW3 Partners, la plateforme de remplacement a été décrite en infrastructure as code et testée de bout en bout avec les modèles d’embeddings.

L’infrastructure as code désigne la description de l’infrastructure dans des fichiers de configuration réutilisables. Pour expliquer cette approche, la documentation de HashiCorp sur Terraform, datée du 19 novembre 2025 dans ses métadonnées décrit des fichiers réutilisables dont on peut conserver les versions et que l’on peut partager. HashiCorp présente leur usage dans Terraform comme un moyen de définir et gérer les ressources de façon reproductible.

Pour la remise au client, nous recommandons d’associer la configuration à la description des essais effectués. Celle-ci devrait préciser le parcours testé, les modèles utilisés et le résultat attendu. Nous proposons aussi de distinguer la vérification du fonctionnement d’un essai de charge : chacun répond à une question différente pour l’exploitation future. Les critères d’acceptation devraient être convenus avec l’équipe qui reprendra la plateforme.

5. Que contient la plateforme cible hébergée en France ?

La cible réunit cluster Kubernetes, GPU L4 et bases managées chez Scaleway en France, avec vLLM et modèles ouverts. La fiche de réalisation TW3 Partners permet de comparer les éléments suivants.

Élément documentéPlateforme existantePlateforme cible
SituationPlateforme IA en production sur un cloud mutualiséAlternative construite et testée de bout en bout
Périmètre décrit153 ressources relevées par APICluster Kubernetes, GPU L4, bases managées
HébergementSocle partagé avec une vingtaine d’autres applicationsScaleway, France
Travail réaliséRelevé des ressources et des risques, examen du poste GPUInfrastructure as code, vLLM et modèles ouverts, essais avec les modèles d’embeddings

Ce tableau sert à situer les travaux documentés. Pour préparer une décision d’hébergement, nous recommandons de le compléter dans le dossier du client par les conditions d’exploitation attendues : accès d’administration, sauvegardes, supervision et support. Les équipes devraient préciser pour chaque fonction qui la fournit et qui en vérifie le fonctionnement.

Le choix d’hébergement fait l’objet de notre article Cloud souverain ou hébergement sur site : où déployer un projet d’IA générative dans le secteur public. Il complète l’étude technique de la cible lorsque la DSI examine ses exigences de maîtrise.

6. Que compare le chiffrage d’une alternative ?

Nous recommandons de chiffrer l’existant et la plateforme proposée sur un périmètre comparable pour éclairer la décision du client. La fiche TW3 Partners décrit une option chiffrée construite et testée ; aucune économie mesurée n’y est publiée.

Pour lire un tel dossier, nous recommandons de demander des réponses écrites aux questions suivantes :

  • Quel périmètre de service est couvert dans chaque option, y compris les ressources partagées ?
  • Quelles hypothèses de charge et de disponibilité servent au calcul ?
  • Quelles tâches d’exploitation restent à la charge du client ?
  • Quels travaux de migration et de validation faut-il prévoir ?
  • Quelle période de coexistence des environnements est envisagée ?
  • Quels engagements contractuels doivent être examinés avant une sortie ?

Nous proposons de présenter séparément les dépenses récurrentes et les travaux de transition. La comparaison devrait conserver les mêmes hypothèses de service et expliciter chaque différence. Si la charge attendue évolue, nous recommandons de refaire le calcul avec cette hypothèse modifiée et d’indiquer les postes affectés. La direction peut ainsi demander une révision ciblée du dossier avant de décider.

7. Comment préparer une migration et répartir les responsabilités ?

Nous recommandons de préparer la migration par un plan qui attribue les travaux et les validations entre client, hébergeur et prestataire. La dernière étape de la réalisation TW3 Partners est un plan de migration accompagné d’une répartition des responsabilités.

Pour préparer ce document, nous recommandons de désigner le responsable de chaque opération, l’équipe qui en vérifie le résultat et la personne qui autorise la poursuite. Le dossier devrait couvrir le déploiement de la cible, la reprise des données, les essais applicatifs et la mise à disposition des accès d’exploitation.

Nous conseillons aussi de préciser les conditions d’une bascule, le retour possible vers l’existant et la clôture de la transition. Le calendrier devrait être convenu avec les responsables des applications concernées. La DSI disposerait alors d’un dossier réunissant l’inventaire, les constats, les hypothèses économiques, la configuration testée et les responsabilités proposées, à soumettre à sa décision de migration.

FAQ

Les faits concernant la réalisation ci-dessous proviennent de la fiche TW3 Partners, relevée le 9 octobre 2026.

Combien de temps prend un audit d’infrastructure IA ?
La durée reste à cadrer pour chaque mission ; la réalisation TW3 ne donne pas de délai. Elle distingue quatre étapes : relevé et cartographie, constats et chiffrage, construction de la cible, puis plan de migration et répartition des responsabilités.

Quel poids le GPU avait-il dans cette réalisation ?
Dans cette réalisation, le poste GPU pesait l’essentiel de la facture. Pour en examiner les causes sur un autre périmètre, nous recommandons de rapprocher la dépense des besoins de calcul et de l’usage observé, avant de proposer une modification.

L’alternative a-t-elle été mise en production ?
Le résultat publié est une plateforme construite et testée, suivie d’un plan de migration. Le choix du client et la mise en production de la cible restent à confirmer.

Où la plateforme cible a-t-elle été construite ?
Scaleway est l’hébergeur cible en France dans la réalisation. Pour un autre projet, nous recommandons de formaliser les critères de choix avec la DSI, puis de confronter l’offre envisagée aux exigences d’exploitation et de maîtrise des données.

Faut-il changer de modèles pour migrer ?
Nous recommandons de vérifier la compatibilité des modèles nécessaires à chaque usage dans l’environnement visé. La cible documentée associe vLLM et des modèles ouverts ; les essais de bout en bout mentionnés portent sur les modèles d’embeddings.

Qu’apporte l’infrastructure as code au client ?
La documentation HashiCorp du 19 novembre 2025 décrit, pour Terraform, des fichiers de configuration que l’équipe peut partager, versionner et réutiliser. Nous recommandons de prévoir leur remise avec les paramètres nécessaires au déploiement et les consignes d’exploitation.

Pour aller plus loin

Sources