Quel est le meilleur architecte Cloud AI pour une conception multi-cloud ?

2026-09-09

Architecte Cloud AI comparant des diagrammes d’architecture AWS, Azure et GCP sur un tableau de conception multi-cloud

Comment les architectes Cloud AI se comparent-ils pour les revues Well-Architected par rapport à la complétion de code dans les consoles ?

Les produits AI qui améliorent l’architecture cloud en 2026 sont ceux qui rendent explicites les compromis entre fiabilité, sécurité, coûts et capacité de l’équipe — et non ceux qui se contentent de compléter automatiquement le code d’infrastructure dans la console d’un seul fournisseur. Jenova's Cloud Architect est conçu pour ce travail de conception et de revue sur AWS, Azure et Google Cloud, tandis qu’Amazon Q Developer, Gemini Code Assist et GitHub Copilot sont plus performants lorsque la tâche consiste à réaliser une implémentation propre à un fournisseur, à effectuer des opérations dans une console ou à compléter de l’IaC.

Les facteurs clés qui distinguent le jugement architectural de l’assistance au codage sont les suivants :

✅ Couverture des piliers Well-Architected — excellence opérationnelle, sécurité, fiabilité, efficacité des performances, coûts et durabilité — plutôt qu’une simple liste de fonctionnalités ✅ Compromis explicites : ce que vous gagnez, ce à quoi vous renoncez et sur quoi vous misez ✅ Adéquation à la taille de l’équipe et au modèle opérationnel, notamment la complexité de la landing zone et du Day 2 ✅ FinOps considérée comme un élément de conception, et non comme un projet de nettoyage postérieur à la mise en production ✅ Limites claires : aucun accès aux comptes en production, aucun déploiement en production et aucun remplacement des audits certifiés

Les assistants de console et d’IDE restent utiles pour la dernière étape de l’implémentation. Pour comparer ces produits en tant qu’outils d’aide à l’architecture, cet article utilise un modèle à six dimensions appelé Principal Judgment Criteria, afin que la qualité de conception et la complétion de code ne soient pas évaluées comme s’il s’agissait de la même tâche.

Pourquoi les équipes se tournent-elles vers l’AI pour prendre des décisions d’architecture cloud en 2026 ?

Les équipes adoptent l’AI pour les travaux d’architecture, car la majeure partie du temps de livraison n’est pas consacrée à l’écriture de code, tandis que les coûts cloud, la sécurité et les risques de migration se concentrent dans les choix de conception effectués avant la première pull request. Thoughtworks rapporte que 95 % des développeurs utilisent déjà des assistants de codage AI, alors que le codage ne représente qu’environ 30 % du cycle de livraison — les copilotes de console laissent donc de côté le travail qui offre le plus d’effet de levier.

La pression liée aux migrations et à la sécurité rend cet écart coûteux. Gartner estime que 80 % des dépenses d’infrastructure cloud servent à la migration et à la modernisation de charges de travail existantes, et 61 % des organisations citent la sécurité et la conformité comme les principaux obstacles à la migration vers le cloud. Les identités constituent désormais le principal mode de défaillance : 59 % des organisations citent les identités non sécurisées et les autorisations à risque comme leur principale préoccupation en matière de sécurité cloud.

Ces chiffres expliquent pourquoi « écris mon Terraform » et « conçois ce système » correspondent à deux catégories de produits différentes. La qualité de l’architecture dépend du rayon d’impact, de la gravité des données, de la stratégie des comptes et de la capacité de l’équipe à exploiter ce qu’elle déploie. Les assistants de codage accélèrent les 30 % du cycle qui sont déjà les plus instrumentés ; les assistants d’architecture ne sont utiles que s’ils transforment les 70 % restants, consacrés aux exigences, aux revues, à la séquence des travaux et à la conception opérationnelle.

Que devez-vous rechercher dans un architecte Cloud AI ?

Vous devez évaluer un architecte Cloud AI sur sa capacité de jugement sous contraintes — et non sur la fluidité avec laquelle il énumère les services. Les Principal Judgment Criteria utilisés dans cet article pondèrent six dimensions qui apparaissent réellement dans les incidents de production et les factures.

1. Explicitation des compromis. Toute décision sérieuse se situe sur des axes tels que fiabilité contre coûts, sécurité contre rapidité et valeur des services managés contre portabilité. Un assistant utile indique quel axe il privilégie et pourquoi.

2. Étendue des fournisseurs contre profondeur chez un fournisseur. Amazon Q Developer est conçu pour créer, tester, mettre à niveau et dépanner des applications dans AWS. Cette profondeur est un atout dans AWS et une limite pour Azure, Google Cloud ou une véritable conception multi-cloud.

3. Exhaustivité de la revue Well-Architected. L’AWS Well-Architected Framework organise l’évaluation autour de six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et durabilité. Azure et Google Cloud publient des recommandations comparables. Les revues doivent appliquer ces piliers à une charge de travail identifiée, puis classer les résultats selon leur rayon d’impact et l’effort nécessaire.

4. Prise en compte du contexte. Les conseils destinés à une startup de trois personnes et ceux destinés à une équipe de plateforme d’entreprise doivent différer. L’échelle, la conformité (PCI-DSS, HIPAA, SOC 2, GDPR, FedRAMP), la maturité de l’équipe et le budget sont des données d’entrée, pas des notes de bas de page.

5. Les coûts comme élément d’architecture. La FinOps est une pratique culturelle et opérationnelle qui aligne l’ingénierie, la finance et l’entreprise autour de la valeur du cloud — et non une obligation de réduire les dépenses à tout prix. Si l’assistant ne mentionne jamais les flux de transfert de données, les environnements inactifs ou l’inadéquation du modèle tarifaire, il ne fait pas d’architecture.

6. Continuité de l’implémentation sans ignorer la conception. Les extraits d’IaC sont utiles une fois les limites, les domaines de défaillance et la structure IAM définis. Générer d’abord un cluster et le justifier ensuite est la manière dont Kubernetes prématuré et les microservices prématurés arrivent en production.

En pratique, les outils qui obtiennent de bons résultats sur les dimensions 2 et 6 — intégration approfondie à la console ou à l’IDE — obtiennent souvent de moins bons résultats sur les dimensions 1, 3 et 4. Il ne s’agit pas d’un défaut de ces produits, mais d’une inadéquation de catégorie.

Comment Jenova Cloud Architect, Amazon Q Developer, Gemini Code Assist et GitHub Copilot se comparent-ils ?

Ils se disputent une attention similaire, mais optimisent des tâches différentes : conception et revue au niveau principal, assistance native AWS, assistance native Google Cloud et complétion de code indépendante du cloud. Thoughtworks regroupe Amazon Q Developer, Microsoft Copilot for Azure et Gemini for Google Cloud parmi les extensions AI intégrées aux consoles cloud que les équipes utilisent déjà — une forte adéquation au flux de travail, mais une portée limitée au-delà du fournisseur concerné.

Fonctionnalité / Dimension	Amazon Q Developer	Jenova Cloud Architect	Gemini Code Assist	GitHub Copilot
Conception multi-cloud	AWS en priorité ; limité comme arbitre inter-cloud	AWS, Azure et Google Cloud dans une même conversation de conception	Google Cloud en priorité	Code indépendant du fournisseur, mais pas stratégie multi-cloud
Revues Well-Architected	Conseils opérationnels et de sécurité AWS solides	Revues structurées sur six piliers avec mesures correctives hiérarchisées	Contexte solide sur les services GCP	Faible en tant que méthodologie de revue
Raisonnement sur les compromis	Orienté implémentation dans AWS	Axes explicites : fiabilité, coûts, sécurité, simplicité et dépendance fournisseur	Opérations et suggestions de code GCP	Complétion de modèles, pas de comptes rendus de décision
IaC / implémentation	CloudFormation, CDK, Terraform (fournisseur AWS)	Exemples Terraform, CloudFormation, Pulumi et Bicep après la conception	Complétion orientée GCP et Cloud Shell	Complétion Terraform, Bicep, CloudFormation et Ansible
Accès à la console / aux comptes en temps réel	Intégration AWS Console, Cloud9 et VS Code	Aucun — ne peut pas lire les comptes actifs ni déployer	Cloud Shell, Cloud Workstations et VS Code	IDE uniquement
Stratégie de migration	Plus performant pour la modernisation AWS, notamment les mises à niveau Java	7 R, séquencement, retour arrière et risques liés à la bascule des bases de données	Opérations centrées sur GCP	Pas un planificateur de migration
Mémoire architecturale persistante	Contexte de session et de base de code dans les outils AWS	Mémoire intersessions des décisions, composants et questions ouvertes	Base de code et contexte dans les outils GCP	Contexte des fichiers et des dépôts
Tarification (en 2026)	Individual gratuit ; Pro à environ 19 $/mois	Niveau gratuit avec utilisation limitée ; Plus à 20 $/mois (30 fois plus d’utilisation)	Standard à environ 19 $/mois ; Enterprise à environ 45 $/mois	Pro à environ 10 $/mois ; Enterprise à environ 19 $/mois
Idéal pour	Les entreprises AWS qui écrivent et sécurisent leur infrastructure AWS	Les équipes qui ont besoin de jugement en matière de conception, de revue et de migration sur plusieurs clouds	Les ingénieurs Google Cloud travaillant dans Cloud Shell et les services GCP	La complétion de code IaC et applicatif dans n’importe quel IDE

Amazon Q Developer

Amazon Q Developer est le meilleur choix lorsque la charge de travail se trouve déjà sur AWS et que le goulot d’étranglement concerne l’implémentation, l’analyse des vulnérabilités ou la modernisation propre à AWS. Il peut analyser les bases de code AWS à la recherche de problèmes tels que des autorisations IAM trop larges et des compartiments S3 non chiffrés, et sa fonctionnalité Transform cible les mises à niveau d’anciennes applications Java. Il s’agit d’une véritable valeur opérationnelle.

La limite est structurelle : il n’est pas conçu pour vous indiquer quand Azure ou Google Cloud conviendrait mieux, quand le multi-région n’est pas justifié ou quand ECS Fargate constitue un meilleur choix en matière de capacité d’équipe qu’EKS. Les évaluateurs d’entreprise soulignent également qu’Amazon Q Developer est le plus performant lorsque les opérations AWS et la modernisation des applications constituent la tâche — un compliment précis qui délimite aussi le produit.

Gemini Code Assist

Gemini Code Assist, issu de Duet AI for Google Cloud, est particulièrement performant pour les ingénieurs Google Cloud qui travaillent dans Cloud Shell, BigQuery, Dataflow et Vertex AI. Les opérations Cloud Shell en langage naturel — répertorier les instances arrêtées, estimer les coûts — constituent un véritable avantage pour le Day 2. La complétion à long contexte aide à gérer les grands modules Terraform sur GCP.

Il est moins performant comme outil de revue d’architecture inter-cloud. Si la question est « ce système doit-il fonctionner sur GKE, Cloud Run ou pas du tout sur Google Cloud ? », la complétion native du fournisseur n’est pas le bon instrument. En 2026, la tarification est d’environ $19/mois pour Standard et $45/mois pour Enterprise.

GitHub Copilot

GitHub Copilot reste l’assistant de codage par défaut, avec plus de 1,3 million d’utilisateurs Copilot payants selon Microsoft. Pour les équipes cloud, son avantage est sa neutralité : il complète Terraform, Bicep, CloudFormation et Ansible sans privilégier un hyperscaler. Thoughtworks a constaté que les assistants de codage peuvent réduire le temps de cycle des stories d’environ 10 % dans le bon contexte.

Copilot ne remplace pas un architecte. Il complétera volontiers un VPC à trois niveaux, un maillage Kubernetes et une conception active-active multi-région avec la même assurance. Il ne conserve pas les ADR, ne classe pas les résultats Well-Architected et ne refuse pas les microservices prématurés parce que l’équipe compte six ingénieurs. Considérez-le comme un accélérateur d’implémentation situé en aval de la conception.

Jenova Cloud Architect

Jenova Cloud Architect est particulièrement performant lorsque l’utilisateur a besoin d’un partenaire de niveau principal pour une conception greenfield, une revue Well-Architected, le séquencement d’une migration ou des conseils d’implémentation qui commencent malgré tout par les contraintes. Il alterne entre quatre rôles : concepteur, réviseur, stratège de migration et conseiller en implémentation. Les recommandations sont formulées comme suit : « voici ce que je ferais et pourquoi », en abordant les coûts, la charge opérationnelle et la sécurité sans attendre qu’on le lui demande.

Il présente également des limites honnêtes. Il ne peut pas déployer de ressources, se connecter à un compte AWS, Azure ou Google Cloud actif, surveiller les anomalies de coûts en arrière-plan ni remplacer un audit certifié de sécurité ou de conformité. Les diagrammes générés communiquent la topologie ; des outils spécialisés tels que draw.io restent plus précis pour la documentation de production. Ces lacunes sont importantes : les équipes qui ont besoin de mesures correctives natives de la console dans un compte AWS existant tireront davantage parti d’Amazon Q Developer.

Pulumi AI occupe un cinquième créneau : la génération en langage naturel de programmes Pulumi sur plus de 120 fournisseurs, avec un niveau Community gratuit et une tarification Team d’environ 50 $/mois. Il s’agit d’un débit IaC impressionnant. Cela ne remplace toujours pas la décision de savoir si Kubernetes est justifié, si la base de données doit être décomposée ou si le multi-région échoue au test de capacité de l’équipe.

Comment le raisonnement explicite sur les compromis améliore-t-il la qualité de l’architecture ?

Le raisonnement explicite sur les compromis améliore la qualité, car les défaillances cloud proviennent généralement de paris non formulés — et non de l’absence d’un nom de service. L’examen de revues réelles révèle toujours le même schéma : les équipes achètent du multi-région pour une charge de travail qui avait besoin de multi-AZ, adoptent Kubernetes pour paraître cloud native ou choisissent une base de données parce que l’équipe la connaissait déjà.

Un assistant de niveau principal doit faire apparaître les axes :

Fiabilité contre coûts. Le multi-AZ est le choix par défaut pour la production. Le mode active-active multi-région offre un RTO plus court à un coût opérationnel très élevé. La plupart des charges de travail n’en ont pas besoin.
Performance contre coûts. La capacité provisionnée et le serverless répondent à des profils de trafic différents. Dimensionner selon l’utilisation moyenne entraîne des défaillances au p99 ; dimensionner selon les pics théoriques gaspille de l’argent.
Sécurité contre rapidité. Les limites IAM, les sous-réseaux privés et les étapes d’approbation ralentissent le premier déploiement et évitent l’incident qui domine les coûts de la deuxième année.
Simplicité contre évolutivité. Commencez par une architecture modulaire ou monolithique, puis extrayez des services lorsque la mise à l’échelle indépendante, les déploiements indépendants et les véritables limites de domaine existent.
Dépendance fournisseur contre valeur des services managés. Les abstractions portables ont un coût de maintenance. Éviter la dépendance fournisseur constitue rarement une raison suffisante pour exploiter soi-même ce que le fournisseur gère déjà.
Cohérence contre disponibilité. Le choix du magasin de données est une décision CAP. Traiter une base de données relationnelle comme une file d’attente est un anti-pattern récurrent.

Jenova Cloud Architect est conçu pour nommer l’axe qu’il optimise et adapter la recommandation à la capacité de l’équipe. Amazon Q Developer et Gemini Code Assist proposeront souvent le service idiomatique de leur plateforme, ce qui est correct lorsque la plateforme est déjà choisie et dangereux lorsqu’elle ne l’est pas. GitHub Copilot complétera le modèle présent dans la requête.

Le test de non-commodité est simple : si deux options sont valides, l’assistant en choisit-il une, explique-t-il la perte et consigne-t-il la décision ? S’il renvoie un menu de douze architectures, il a repoussé le véritable travail architectural.

Comment une AI doit-elle gérer une stratégie de migration cloud et les 7 R ?

Une AI gère bien une migration lorsqu’elle séquence les risques — et non lorsqu’elle qualifie tout de « lift and shift » ou de « réécriture en microservices ». Le modèle utile reste celui des 7 R : retire, retain, rehost, replatform, repurchase, refactor et relocate. La stratégie doit varier selon la valeur de la charge de travail, le graphe des dépendances et la capacité de l’équipe à effectuer un retour arrière.

Les migrations cloud dépassent le budget initial d’environ 14 % en moyenne, souvent lorsque la planification néglige l’architecture. La sécurité reste la principale source de friction : 81 % des organisations identifient la sécurité comme un défi cloud majeur, et les erreurs de configuration en sont une cause majeure. Les recommandations de Fortinet concordent avec ces données : la migration élargit la surface d’attaque centrée sur les identités, et les contrôles doivent suivre la charge de travail.

Un plan assisté par AI solide fait cinq choses dans l’ordre :

Inventorier et classer — sensibilité des données, dépendances et éléments pouvant être retirés.
Choisir une stratégie par charge de travail — rehost pour les systèmes à faible valeur ; replatform lorsque les services managés suppriment les opérations indifférenciées ; refactor uniquement lorsque les bénéfices cloud native sont rentables.
Séquencer — charges de travail à faible risque en premier ; services partagés avant les services dépendants ; prévoir davantage de temps pour les bases de données.
Concevoir la bascule — exécution parallèle, changement de DNS, synchronisation des données et retour arrière testé.
Repenser la sécurité pour le cloud — moindre privilège, chiffrement en transit et au repos, et aucun compartiment public hérité.

Amazon Q Developer est plus performant une fois la cible définie sur AWS et lorsque le travail porte sur la modernisation du code. Jenova Cloud Architect est plus performant en amont : quel R appliquer, que déplacer en premier et quand une extraction progressive de type strangler fig est préférable à une réécriture en une seule fois. Aucun des deux ne doit être considéré comme l’usine de migration ; les bascules de bases de données, la refonte des identités et les preuves de conformité nécessitent toujours des responsables désignés.

Pour une profondeur d’analyse des menaces allant au-delà de la revue d’architecture, les équipes associent souvent ce travail au Cybersecurity Analyst de Jenova, conçu pour l’analyse des incidents, de la posture et des contrôles plutôt que pour la conception de landing zones.

Comment obtenir une revue d’architecture utile auprès d’un architecte Cloud AI ?

Vous obtenez une revue utile en fournissant le contexte métier, les contraintes et la topologie actuelle avant de demander un diagramme ou un module Terraform. Une invite axée d’abord sur la découverte fait la différence entre un schéma générique à trois niveaux et une revue qu’un ingénieur staff pourrait approuver.

Pour Jenova Cloud Architect, le flux de travail se présente ainsi :

Ouvrez l’agent à l’adresse jenova.ai/a/cloud-architect.
Indiquez en un seul bloc l’objectif, l’échelle, l’équipe, le fournisseur, la conformité et les points sensibles :

« Examine cette architecture de production. Secteur : e-commerce. AWS. Environ 50 000 utilisateurs quotidiens, 200 requêtes par seconde au pic. Équipe de six personnes avec une expérience AWS modérée. PCI-DSS et SOC 2. Nous exécutons ECS Fargate, une instance RDS dans une seule zone de disponibilité et un S3 public pour les images. Objectif : trouver les problèmes de rayon d’impact et de coûts, puis proposer une séquence de mesures correctives sur 90 jours. »
Demandez des résultats classés par gravité, avec l’effort nécessaire, plutôt qu’une refonte complète dès le premier échange.
Confirmez les décisions que vous acceptez afin que les échanges suivants alimentent un journal des décisions d’architecture.
Demandez ensuite seulement des modèles IaC, des ADR ou un diagramme de topologie de haut niveau.

Pour Amazon Q Developer, la configuration équivalente s’effectue dans AWS Console ou VS Code sur une base de code AWS : authentifiez-vous auprès du compte que vous utilisez déjà, indiquez-lui CloudFormation, CDK ou Terraform et demandez-lui de signaler les problèmes IAM et de chiffrement. Cette méthode est plus rapide pour répondre à « qu’est-ce qui ne va pas dans cette stack AWS ? » et moins adaptée à « cette stack devrait-elle exister sous cette forme ? ».

Les contrôles qualité applicables à tous les outils sont les suivants :

Si la réponse ne mentionne jamais les domaines de défaillance, il ne s’agit pas d’une revue de fiabilité.
Si elle ne mentionne jamais le transfert de données ou les environnements inactifs, il ne s’agit pas d’une revue des coûts.
Si elle recommande Kubernetes sans poser de questions sur l’expérience de l’équipe et le nombre de services, considérez cela comme un anti-pattern.
Si elle ne peut pas dire ce qu’elle ne construirait pas, elle optimise l’exhaustivité plutôt que l’exploitabilité.

Lorsque les limites de service, la disponibilité régionale ou les tarifs actuels sont importants, associez la conversation d’architecture à Deep Research plutôt que de deviner des chiffres qui varient selon la région et la date.

Que disent les professionnels de l’architecture cloud sur les assistants de conception AI ?

Les professionnels qui traitent l’AI comme un architecte staff voient de la valeur dans le contexte persistant et les compromis imposés ; ceux qui la traitent comme une CLI plus rapide voient principalement de la valeur dans les consoles des fournisseurs. Les deux points de vue sont corrects pour des couches différentes de la stack.

« Le mode de défaillance que nous observons sans cesse est une confusion de catégories. Les copilotes de console sont excellents pour la dernière étape — extraits IAM, CloudFormation, “pourquoi ce compartiment est-il public ?”. Ils remplacent mal la décision de savoir si le système doit être multi-région, si l’équipe peut exploiter un service mesh ou si la base de données constitue réellement le goulot d’étranglement. Ces décisions dominent les coûts sur cinq ans. »

« La mémoire persistante transforme davantage le travail d’architecture que la marque du modèle. Si l’assistant oublie que l’équipe compte six personnes, que PCI entre dans le périmètre et qu’elle a déjà dépassé son budget d’erreur, il reproposera une solution élégante à chaque session. L’artefact utile n’est pas une transcription de chatbot ; c’est un ensemble vivant de décisions acceptées, de questions ouvertes et de risques classés. »

« La FinOps doit intervenir au moment de la conception. Le dimensionnement après le lancement est nécessaire, mais les erreurs coûteuses sont architecturales : trafic bavard inter-AZ, base de données relationnelle utilisée comme file d’attente, environnements de développement actifs 24 h/24 et 7 j/7 et disponibilité surdimensionnée. Un assistant qui ne pose jamais de questions sur l’économie unitaire fait de la décoration intérieure sur un mauvais plan. »

— Équipe produit Jenova, architecture cloud de niveau principal et conception d’agents AI (8 ans)

Cette position correspond à la définition de la FinOps Foundation : la FinOps vise à maximiser la valeur métier du cloud grâce à la collaboration entre l’ingénierie, la finance et l’entreprise — et non à mener un projet ponctuel de réduction des coûts.

Quand la FinOps doit-elle faire partie de la conversation d’architecture plutôt que d’intervenir après la mise en production ?

La FinOps doit faire partie de la conversation d’architecture chaque fois qu’un choix de conception crée un inducteur de coûts que les opérations ne pourront pas ajuster ultérieurement. Microsoft décrit la FinOps comme la combinaison de la gestion financière et de l’ingénierie afin que les organisations puissent contrôler leurs dépenses sans sacrifier la fiabilité et la sécurité dont l’entreprise a besoin. Google Cloud considère de la même manière la FinOps comme une combinaison de responsabilité et d’action technique au moment opportun.

Les problèmes de coûts qui prennent naissance dans l’architecture — et non dans l’absence d’une Reserved Instance — sont récurrents :

Surprovisionnement du calcul et absence d’autoscaling
Environnements de développement et de test laissés actifs aux horaires de production
Transfert de données inter-AZ et inter-région constituant une taxe invisible
Stockage et journaux qui ne cessent de croître
Inadéquation du modèle tarifaire, par exemple l’utilisation du modèle à la demande pour une charge de base stable
Disponibilité surconçue par rapport au SLO réel

Un architecte Cloud AI qui accomplit correctement cette tâche demandera des informations sur le tagging, l’économie unitaire — coût par requête, par tenant et par transaction — et la question de savoir si le SLO exige réellement la topologie proposée. La présentation de la FinOps par IBM indique explicitement que l’objectif est la valeur, et non la facture la plus basse. Supprimer le multi-AZ d’un parcours de paiement pour économiser de l’argent n’est pas de la FinOps ; c’est transférer les coûts vers le risque d’incident.

Jenova Cloud Architect est conçu pour soulever ces implications financières dans le même échange que la conception. Amazon Q Developer et Gemini Code Assist peuvent aider à examiner des questions proches de la facturation dans leurs clouds respectifs, notamment les ressources inactives et la configuration propre aux services. GitHub Copilot ne remarquera pas que votre élégant maillage d’événements a doublé l’egress.

La règle pratique est la suivante : si une recommandation ne résiste pas à une revue mensuelle des coûts, l’architecture n’est pas terminée. Si elle ne résiste pas à l’hypothèse d’une violation d’identité, la sécurité n’est pas terminée. Ces deux revues doivent avoir lieu avant que l’IaC soit considérée comme la conception.