Le guide complet de Stack Automation : tarifs, fonctionnalités et retour sur investissement

Étape 1 : qu’est-ce que Stack Automation et comment fonctionne-t-il ?

Stack Automation est une plateforme d’automatisation des déploiements développée conjointement par Cisco et Quali. Elle automatise l’ensemble du processus, de la baie à l’application, et ramène les délais de déploiement de plusieurs semaines à quelques heures. Elle prend en charge le déploiement de logiciels Cisco, d’applications tierces et de solutions complètes préassemblées, avec les garanties offertes par les Cisco Validated Designs.

Concrètement, vous choisissez un blueprint dans un catalogue central, puis vous configurez vos variables. La plateforme orchestre ensuite le provisionnement des couches physiques, virtuelles et cloud dans le strict respect de leurs dépendances.

Le processus se déroule en trois phases :

1. Planification initiale : vous parcourez les centaines de blueprints préconçus du Solutions Hub. Chacun correspond à un Cisco Validated Design. Il vous suffit de choisir celui qui convient à votre matériel et à votre charge de travail.
2. Déploiement : la plateforme exécute le blueprint et provisionne le réseau, le calcul, le stockage et les applications dans l’ordre imposé par leurs dépendances. Nous utilisons aussi Stack Automation pour déployer des solutions complètes comme les Cisco AI PODs dans le cadre d’une prestation ponctuelle. Vous pouvez également le faire vous-même.
3. Exploitation : la plateforme surveille les environnements déployés pour détecter les dérives de configuration, compare leur état au blueprint validé et attribue les coûts aux équipes responsables.

Voici comment s’articule l’architecture :

La pression du marché est bien réelle. Il ne s’agit pas d’une évolution progressive, mais d’un changement de cap radical : les charges de travail IA exigent des piles étroitement intégrées, dont les configurations réseau, de calcul et de stockage ont été validées ensemble, sans exception. Une analyse de notre propre site l’a confirmé : le provisionnement manuel absorbait 40 % de la capacité hebdomadaire de notre équipe infrastructure.

Après le passage aux déploiements pilotés par blueprint, cette part est tombée sous les 5 %.

Pourquoi le modèle fondé sur les blueprints compte

Les outils d’automatisation classiques vous fournissent les composants, mais vous devez encore les assembler. Stack Automation fournit des solutions déjà assemblées et validées. C’est la différence entre acheter des planches et acheter un mur préfabriqué.

Pour les AI PODs en particulier, c’est important : les dépendances entre le provisionnement des GPU, la configuration du réseau et la hiérarchisation du stockage sont si complexes qu’un assemblage manuel présente un risque inacceptable. La plateforme ne remplace pas vos outils d’automatisation existants. Elle les orchestre.

Les scripts Terraform, Ansible, Helm et Python s’intègrent tous au Blueprint Designer comme ressources réutilisables. Vous ne réécrivez donc pas vos automatisations, vous les combinez.

Étape 2 : comparer les formules Stack Automation, Essentials et Advantage

La plateforme propose deux formules : Essentials (gratuite) pour les déploiements standard à partir du catalogue et Advantage (sur abonnement) pour la personnalisation avancée et GitOps. La distinction paraît simple, mais ses conséquences le sont moins. Essentials vous permet de démarrer avec des blueprints préconçus.

Advantage donne accès aux personnalisations nécessaires en production.

Les deux formules donnent accès à un Solutions Hub centralisé, qui contient des centaines de blueprints préconçus pour la planification initiale. Le Blueprint Designer permet d’intégrer par glisser-déposer des ressources d’automatisation Terraform, Ansible, Helm et Python aux processus. Mais c’est ici que les deux formules divergent nettement.

Comparatif des fonctionnalités

Les coûts cachés de la formule gratuite

Essentials semble gratuit, et il l’est. Mais ses limites se cumulent vite :

• Vous ne pouvez pas modifier les blueprints pour les adapter à votre topologie réseau existante.
• La détection des dérives vous alerte, mais ne corrige pas le problème.
• Sans GitOps, vous ne disposez pas d’un historique des déploiements avec gestion des versions.
• Le déploiement d’applications tierces personnalisées est limité à un catalogue restreint.

La création d’AiGrow nous a appris une chose : c’est dans l’écart entre « gratuit » et « prêt pour la production » que la plupart des équipes sous-estiment les coûts. Vous économisez sur les licences, mais vous consacrez davantage d’heures aux corrections manuelles.

Calculateur de coûts

Quelle formule choisir ?

Choisissez Essentials si : vous êtes une petite équipe qui déploie des Cisco AI PODs standard avec peu de personnalisation. Cette formule convient aux projets pilotes et aux preuves de concept, lorsque vous devez évaluer la plateforme avant d’y consacrer un budget.

Choisissez Advantage si : vous gérez des environnements de production avec plusieurs équipes, des topologies réseau personnalisées, des pipelines CI/CD pilotés par GitOps et des applications tierces à intégrer. Si la correction des dérives compte pour vous, c’est la seule formule qui la propose.

Voici un exemple de payload envoyé par un webhook GitOps qu’Advantage utilise pour déclencher le déploiement d’un blueprint :

{
  "event": "push",
  "repository": "infra/ai-pod-configs",
  "branch": "production",
  "blueprint": "cisco-ai-pod-nvidia-h100",
  "variables": {
    "gpu_count": 8,
    "storage_tier": "premium",
    "network_fabric": "aci"
  },
  "trigger": "stack-automation-advantage",
  "validation": "cisco-validated-design"
}

Étape 3 : comment l’IA agentique permet-elle à Stack Automation de corriger automatiquement les problèmes ?

Dans l’automatisation de la stack, l’IA agentique consiste à intégrer des agents IA autonomes comme NVIDIA NemoClaw et Claude. Ils génèrent, améliorent et réparent automatiquement les configurations d’infrastructure lors du déploiement initial, sans vous enfermer dans une technologie propriétaire. Ce déploiement permet de provisionner rapidement et automatiquement les infrastructures physiques, virtuelles et cloud.

La couche agentique est intégrée au Blueprint Designer et utilise vos ressources Terraform, Ansible et Python existantes.

Le principe est simple, même si sa mise en œuvre technique est complexe. Lorsqu’un blueprint est exécuté, l’IA agentique surveille le déploiement en temps réel. Si une étape de configuration échoue, l’agent analyse l’erreur, génère une configuration corrigée et réessaie.

Aucune intervention humaine n’est nécessaire et aucun ticket n’est mis en attente.

Ce qui distingue les agents

Le point essentiel : les outils d’IA agentique génèrent, améliorent et réparent automatiquement les configurations sans créer de dépendance propriétaire. Vos modules Terraform restent des modules Terraform, et vos playbooks Ansible restent des playbooks Ansible. Les agents modifient les entrées et les paramètres, pas les outils sous-jacents.

Un exemple concret

Imaginez qu’un déploiement échoue parce que le marquage VLAN de la configuration réseau ne correspond pas à celui du commutateur physique. Une automatisation classique s’arrête, signale une erreur et attend une intervention humaine. Dans une stack automatisée, l’IA agentique détecte cet écart, interroge l’état du commutateur via une API, régénère la configuration VLAN et relance le déploiement.

Voici à quoi ressemble ce processus d’auto-réparation :

L’agent consigne chaque modification. Vous disposez ainsi d’une piste d’audit complète. Si la correction proposée par l’IA ne vous convient pas, vous pouvez rétablir la configuration initiale et appliquer la vôtre. La plateforme permet toujours de revenir en arrière après une décision automatisée.

Et pour les opérations après le déploiement ?

L’auto-réparation ne s’arrête pas au déploiement initial. La même couche agentique détecte les écarts de configuration pendant les opérations courantes. Si un membre de l’équipe modifie manuellement une règle de pare-feu sur un commutateur en production, l’agent repère l’écart par rapport au blueprint validé, détermine si la modification est intentionnelle ou accidentelle, puis la consigne ou lance une correction selon les règles que vous avez définies.

C’est ce qui distingue l’automatisation de la stack des outils génériques d’infrastructure en tant que code. La couche d’IA apporte une boucle de rétroaction dont la plupart des plateformes sont totalement dépourvues.

Un autre point de vue : pourquoi le déploiement de solutions couvrant toute la stack n’est pas toujours le meilleur choix

Le déploiement de solutions couvrant toute la stack ne convient pas à toutes les situations. Nous avons vu des équipes adopter à la hâte des plateformes monofournisseur d’automatisation de la stack sans se demander si leur environnement s’y prêtait réellement. Ce n’est pas toujours le cas.

Une plateforme optimisée pour Cisco Validated Designs gère remarquablement bien l’infrastructure sur site. Les choses se compliquent avec le cloud et les environnements conteneurisés.

Les plateformes d’orchestration et d’automatisation des services (SOAPs) sont une évolution de l’automatisation traditionnelle des charges de travail (WLA) introduite par Gartner. Elles coordonnent des outils d’automatisation spécialisés plutôt que de les remplacer, et servent de centre d’orchestration pour l’entreprise. L’automatisation de la stack est excellente dans le périmètre des outils Cisco.

Mais si votre environnement réunit AWS, Azure, des clusters Kubernetes et du matériel Cisco sur site, aucune plateforme ne couvre tous ces éléments aussi bien.

Les limites du déploiement de toute la stack

• Les environnements multicloud où chaque cloud dispose d’outils d’automatisation natifs plus complets que les abstractions multiplateformes.
• Les systèmes existants antérieurs à l’automatisation moderne pilotée par API, qui nécessitent des scripts d’intégration sur mesure.
• Les environnements soumis à des exigences de conformité où les modifications de configuration doivent être approuvées par un comité de gestion des changements avant tout déploiement.
• Les équipes ayant déjà beaucoup investi dans leurs outils comme Terraform Cloud, Ansible Automation Platform ou ArgoCD, dont une nouvelle plateforme ferait partiellement double emploi.

Le risque de multiplier les outils

Adopter une nouvelle plateforme d’orchestration pour réduire le nombre d’outils peut produire l’effet inverse si elle ne remplace aucun outil existant. Si votre équipe utilise Terraform pour le cloud, Ansible pour la gestion des configurations, ArgoCD pour Kubernetes et Jenkins pour le CI/CD, ajouter l’automatisation de la stack comme cinquième outil ne résout pas le problème. Cela en ajoute un sixième.

La bonne question est de savoir si la plateforme sert de centre d’orchestration ou crée un silo supplémentaire. L’automatisation de la stack intègre les outils existants via le Blueprint Designer, mais le degré d’intégration compte. Une interface de glisser-déposer autour d’un module Terraform n’équivaut pas à Terraform Cloud et à son application native de règles sous forme de code.

Quand une plateforme monofournisseur est pertinente

Nous ne déconseillons pas le déploiement de solutions couvrant toute la stack. Nous déconseillons d’en faire le choix par défaut. Les plateformes monofournisseur d’automatisation de la stack sont particulièrement pertinentes si :

1. Votre infrastructure est principalement composée d’équipements Cisco. 2. Vous déployez des charges de travail IA qui bénéficient de conceptions couvrant toute la stack et préalablement validées.
2. Votre équipe a besoin de processus guidés faute d’une expertise approfondie en automatisation.
3. Vous partez de zéro, sans investissement préalable dans des outils.

Si les quatre points vous concernent, l’automatisation de la stack est une option solide. Si vous n’en cochez pas plus de deux, évaluez d’abord les SOAPs capables de coordonner vos outils existants avant d’ajouter une nouvelle plateforme.

Étape 4 : évaluer l’automatisation de la stack pour les environnements informatiques hybrides

L’automatisation de la stack se commande sur Cisco CCW auprès de n’importe quel partenaire Cisco. Cela révèle un point important : cette plateforme est centrée sur Cisco. Elle n’est pas présentée comme un outil d’orchestration indépendant des fournisseurs.

Il faut en tenir compte avant de l’évaluer pour un environnement hybride.

La plateforme peut déployer des infrastructures non Cisco grâce à son Blueprint Designer, mais les blueprints prêts à l’emploi restent très majoritairement axés sur Cisco. Nous utilisons l’automatisation de la stack pour déployer des solutions couvrant toute la stack, comme Cisco AI PODs, dans le cadre d’une prestation ponctuelle. Pour le matériel non Cisco, vous devez créer des blueprints personnalisés de toutes pièces.

La réalité des environnements informatiques hybrides

Prérequis pour déployer du matériel non Cisco

Avant de déployer l’automatisation de la stack dans un environnement hybride, vérifiez les points suivants : vous devez disposer d’un accès API pour chaque composant non Cisco, du niveau Advantage pour créer des blueprints personnalisés, et prendre en charge leur validation pour le matériel non Cisco, que Cisco Validated Designs ne couvre pas. L’assistance Cisco couvre la plateforme et les blueprints Cisco, mais les problèmes de déploiement sur du matériel non Cisco nécessitent de faire appel au fournisseur concerné.

La place de l’automatisation de la stack parmi les outils SOAP

L’automatisation de la stack n’est pas une SOAP au sens défini par Gartner. C’est une plateforme d’automatisation des déploiements dont le périmètre est plus restreint. Une SOAP coordonne les charges de travail dans toute l’entreprise.

L’automatisation de la stack orchestre le déploiement de l’infrastructure au sein d’une stack donnée.

Si vous utilisez déjà une SOAP, demandez-vous si l’automatisation de la stack s’y intègre ou entre en concurrence avec elle. La réponse dépend de la maturité des API de votre SOAP. La plupart des SOAPs modernes exposent des API REST qui permettent de déclencher des déploiements dans le cadre d’un processus plus large.

L’intégration fonctionne, mais elle n’est pas profondément native.

Une évaluation réaliste

Voici notre constat après avoir évalué la plateforme dans des environnements mixtes. L’automatisation de la stack excelle lorsque l’infrastructure est dominée par Cisco. Elle reste utilisable dans les environnements mixtes, mais demande beaucoup d’efforts.

Ce n’est pas le bon outil si votre infrastructure est composée à plus de 90% de matériel non Cisco.

Le cadre de décision est simple :

L’automatisation de la stack peut accroître la complexité si ses hypothèses ne correspondent pas à votre environnement. Avant de l’adopter, évaluez les interfaces prises en charge, la répartition des responsabilités d’exploitation, la reprise après incident et les charges de travail.

Étape 5 : calculer le retour sur investissement et éviter la dépendance à un fournisseur avec l’automatisation de la stack

Pour calculer le ROI de Stack Automation, il faut des chiffres concrets, pas de vagues promesses de productivité. Voici un exemple chiffré que vous pourrez adapter à votre environnement.

La formule du ROI

Votre ROI repose sur trois sources d’économies : la réduction du temps de provisionnement, la diminution des erreurs de configuration et la réduction du travail nécessaire pour corriger les écarts de configuration après la mise en service. Stack Automation surveille les environnements déployés pour repérer les écarts par rapport aux configurations de référence validées et attribue les coûts aux équipes responsables. La plateforme est conçue pour relier la planification initiale aux opérations courantes, tout en réduisant les risques liés aux points de défaillance uniques.

Exemple chiffré

Prenons une entreprise de taille moyenne qui déploie 4 AI PODs par trimestre. Voici la répartition des coûts.

Vous économisez $60,000 par an. Le seuil de rentabilité est atteint au 8e mois de la 1re année. À la fin de la 2e année, la plateforme s’est amortie et a généré $72,000 d’économies nettes supplémentaires.

Éviter la dépendance à un fournisseur

La crainte d’une dépendance à un fournisseur est légitime. Voici comment Stack Automation la limite :

1. Outils ouverts : Vos modules Terraform, playbooks Ansible et scripts Python restent portables. La plateforme les orchestre sans les convertir dans des formats propriétaires.
2. Possibilité d’exportation : Les configurations de référence peuvent être exportées sous forme d’artefacts IaC standard. Vous n’êtes pas prisonnier d’un DSL propriétaire.
3. Conception axée sur les API : Chaque fonction de la plateforme est accessible par API REST. Vous pouvez donc créer une autre couche d’orchestration si nécessaire.
4. Transparence des agents : Les configurations des agents IA sont consignées et réversibles. Aucun changement ne se fait dans une boîte noire.

Contexte du marché pour cet investissement

Le marché évolue. La question n’est pas de savoir s’il faut investir dans l’automatisation, mais quelle plateforme convient à votre environnement.

Comment fonctionne la détection des écarts de configuration

Voici, sur le plan technique, comment les écarts de configuration sont détectés après la mise en service :

{
 "drift_event": {
 "environment": "ai-pod-production-01",
 "component": "network_fabric",
 "expected_state": {"vlan": 100, "mtu": 9000},
 "actual_state": {"vlan": 100, "mtu": 1500},
 "severity": "high",
 "owning_team": "network-ops",
 "monthly_cost_attribution": {
 "compute": "$12,400",
 "storage": "$3,200",
 "network": "$1,800",
 "team": "network-ops"
 },
 "remediation_action": "agent_auto_fix_pending_approval",
 "blueprint_reference": "cisco-ai-pod-nvidia-h100-v3"
 }
}

Ces données sont transmises aux équipes responsables. L’attribution des coûts n’est pas un simple bonus : c’est ce qui permet de rendre chaque équipe responsable de l’infrastructure qu’elle consomme. Sans elle, les coûts du cloud et des infrastructures sur site augmentent sans qu’on s’en aperçoive.

Verdict

Stack Automation convient surtout : Aux environnements largement équipés en Cisco qui déploient des charges de travail IA et où les configurations de référence prévalidées réduisent les risques et le temps de provisionnement. La plateforme convient aussi aux équipes qui souhaitent un déploiement guidé sans devoir créer leur automatisation de zéro.

Moins adapté : Aux environnements privilégiant le multicloud, fortement investis dans leurs outils existants et disposant de peu de matériel Cisco, ainsi qu’aux équipes qui ont besoin d’une orchestration indépendante des fournisseurs sur une infrastructure hétérogène. Et les cas particuliers ?