Discussion :

[Anthony]

Amazon AWS lance Kiro, un nouvel EDI dirigé par les spécifications pour le vibe coding avec des agents IA intégrés, qui fonctionne du prototype à la production à travers une expérience développeur simplifiée

Amazon Web Services (AWS) a lancé Kiro, un nouvel EDI intégrant l'IA, actuellement en preview, qui aide les développeurs à transformer leurs idées en code prêt pour la production grâce à l'IA. Contrairement à d'autres EDI agentiques comme Windsurf Editor, Firebase Studio ou Cursor, Kiro se concentre sur des spécifications structurées plutôt que sur des prompts (instructions génératives). Sa fonction Kiro Specs permet notamment aux développeurs de définir les exigences du projet, qui sont ensuite traduites en notation EARS (Easy Approach to Requirements Syntax).

Kiro utilise ces spécifications ou les bases de code existantes pour générer automatiquement des documents de conception, notamment des interfaces TypeScript, des points d'extrémité d'API, des schémas de base de données et des diagrammes de flux de données. Il décompose le développement en tâches et sous-tâches, telles que les tests et l'accessibilité, chacune pouvant être déclenchée et exécutée avec l'aide de l'IA.

Construit sur l'architecture open-source Visual Studio Code, Kiro prend en charge les principaux langages de programmation et est compatible avec Linux, macOS et Windows. Il utilise par défaut le modèle Claude Sonnet 4 d'Anthropic, avec la version 3.7 comme sauvegarde, et d'autres options de modèles sont en cours d'élaboration.

Pour étendre ses fonctionnalités, Kiro s'intègre à des outils externes via le Model Context Protocol et prend en charge des automatisations événementielles appelées Kiro Hooks, qui déclenchent des actions telles que des analyses de code ou des mises à jour de la documentation en cas de modification des fichiers. Il comprend également un assistant de codage IA pour le développement inline.

La version de prévisualisation de Kiro est actuellement gratuite, les plans payants commençant à 19 euros par mois lors du lancement ultérieur.

Présentation de Kiro

Certains développeurs sont probablement passé par là : un prompt, un autre prompt, puis un autre, et l'on obtient une application qui fonctionne. C'est amusant et cela ressemble à de la magie. Mais pour la mettre en production, il faut aller plus loin. Quelles hypothèses le modèle a-t-il formulées lors de sa construction ? Le développeur a guidé l'agent tout au long du processus, mais ces décisions ne sont pas documentées. Les exigences sont floues et le développeur ne peut pas savoir si l'application y répond. Il ne peut pas comprendre rapidement comment le système est conçu et comment cette conception affectera son environnement et ses performances. Parfois, il est préférable de prendre du recul, de réfléchir aux décisions, et l'on obtient une meilleure application dont on pourra facilement assurer la maintenance. C'est ce que Kiro aide à faire grâce au développement dirigé par les spécifications.

AWS a le plaisir d'annoncer Kiro, un EDI pour l'IA qui vous aide à passer du concept à la production grâce à une expérience de développement simplifiée pour travailler avec des agents d'IA. Kiro est excellent pour le « vibe coding », mais va bien au-delà : sa force est de transformer ces prototypes en systèmes de production grâce à des fonctionnalités telles que les spécifications et les hooks.

Les spécifications de Kiro sont des artefacts qui s'avèrent utiles à chaque fois qu'un développeur a besoin de réfléchir en profondeur à une fonctionnalité, à un travail de refactorisation qui nécessite une planification en amont, ou lorsqu'il veut comprendre le comportement des systèmes - en bref, la plupart des choses dont le développeur a besoin pour passer à la production. Les exigences sont généralement incertaines quand on commence à construire, c'est pourquoi les développeurs utilisent des spécifications pour la planification et la clarté. De la même manière, les spécifications peuvent guider les agents d'IA vers une meilleure mise en œuvre.

Les hooks de Kiro agissent comme un développeur expérimenté en rattrapant les choses que vous manquez ou en effectuant des tâches banales en arrière-plan pendant que vous travaillez. Ces automatismes événementiels déclenchent l'exécution d'une tâche en arrière-plan par un agent lorsque le développeur enregistre, crée ou supprime des fichiers, ou sur déclenchement manuel.

Construire avec des spécifications et des hooks

Kiro accélère le flux de travail des spécifications en l'intégrant davantage au développement. Dans cet exemple, on dispose d'une application de commerce électronique pour la vente d'objets artisanaux, à laquelle on souhaite ajouter un système d'évaluation permettant aux utilisateurs de laisser des commentaires sur les objets artisanaux. Voici le processus en trois étapes de la construction avec les spécifications.

L'application de commerce électronique avec laquelle on travaille

1. D'un prompt unique aux exigences

Kiro décompose les exigences à partir d'un prompt unique - « Ajouter un système d'évaluation pour les produits » - et génère des histoires d'utilisateurs pour l'affichage, la création, le filtrage et l'évaluation des évaluations. Chaque histoire d'utilisateur inclut les critères d'acceptation de la notation EARS couvrant les cas limites que les développeurs traitent généralement lorsqu'ils construisent à partir d'histoires d'utilisateur de base. Les prompts d'hypothèses des développeurs sont ainsi explicites, ce qui leur permet de savoir que Kiro construit ce qu'il veulent.

Spécifications des exigences Kiro

2. Conception technique basée sur les exigences

Kiro génère ensuite un document de conception en analysant la base de code et les exigences approuvées. Il crée des diagrammes de flux de données, des interfaces TypeScript, des schémas de base de données et des points de terminaison API, comme les interfaces Review pour le système d'évaluation en cours de construction. Cela élimine les longs allers-retours sur la clarté des exigences qui ralentissent généralement le développement.

Spécifications de conception Kiro avec interfaces, diagrammes de flux de données

3. Implémentation des tâches

Kiro génère des tâches et des sous-tâches, les séquence correctement en fonction des dépendances et les relie aux exigences. Chaque tâche comprend des détails tels que les tests unitaires, les tests d'intégration, les états de chargement, la réactivité mobile et les exigences d'accessibilité pour l'implémentation. Cela permet au développeur de vérifier le travail par étapes plutôt que de découvrir des pièces manquantes une fois qu'il pense avoir terminé.

Kiro simplifie l'ensemble du processus en générant automatiquement les tâches et les sous-tâches, en les séquençant dans le bon ordre et en reliant chaque tâche aux exigences afin que rien ne passe à travers les mailles du filet. Comme on peut le voir ci-dessous, Kiro a pensé à écrire des tests unitaires pour chaque tâche, a ajouté des états de chargement, des tests d'intégration pour l'interaction entre les produits et les revues, et le responsive design et l'accessibilité.

L'interface des tâches permet au développeur de déclencher des tâches une par une avec un indicateur de progression montrant l'état d'exécution. Une fois la tâche terminée, il peut en voir l'état d'achèvement en ligne et auditer le travail en visualisant les différences de code et l'historique de l'exécution de l'agent.

Les spécifications de Kiro restent synchronisées avec l'évolution de la base de code. Les développeurs peuvent créer du code et demander à Kiro de mettre à jour les spécifications ou de les mettre à jour manuellement pour actualiser les tâches. Cela résout le problème courant des développeurs qui cessent de mettre à jour les artefacts originaux au cours de la mise en œuvre, ce qui entraîne des incohérences dans la documentation qui compliquent la maintenance future.

4. Identifier les problèmes avant qu'ils ne soient expédiés avec des hooks

Avant de soumettre leur code, la plupart des développeurs passent par une liste de contrôle mentale : Ai-je cassé quelque chose ? Les tests sont-ils mis à jour ? La documentation est-elle à jour ? Cette prudence est saine, mais sa mise en œuvre peut nécessiter beaucoup de travail manuel.

Les hooks de l'agent Kiro agissent comme un développeur expérimenté qui rattrape les choses que le développeur peut manquer. Les hooks sont des automatismes pilotés par des événements qui s'exécutent lorsqu'un développeur enregistre ou crée des fichiers - c'est comme déléguer des tâches à un collaborateur. Configurez un hook une fois, et Kiro s'occupe du reste. Voici quelques exemples :

• Lorsqu'un développeur sauvegarde un composant React, les hooks mettent à jour le fichier de test.
• Lorsqu'un développeur modifie les points de terminaison de l'API, les hooks actualisent les fichiers README.
• Lorsqu'un développeur est prêt à livrer, les hooks de sécurité analysent les fuites d'informations d'identification.

Les hooks assurent la cohérence de l'ensemble de l'équipe. Tout le monde bénéficie des mêmes contrôles de qualité, des mêmes normes de code et des mêmes correctifs de validation de la sécurité. Pour la fonctionnalité d'évaluation construite, on veut s'assurer que tout nouveau composant React respecte le principe de la responsabilité unique afin que les développeurs ne créent pas des composants qui font trop de choses. Kiro prend le prompt créé par le développeur, génère un prompt système optimisé et sélectionne les dossiers du référentiel à surveiller. Une fois que ce hook est committé sur Git, il applique la norme de codage à l'ensemble de l'équipe - chaque fois que quelqu'un ajoute un nouveau composant, l'agent le valide automatiquement par rapport aux directives.

Création d'un hook pour déclencher l'enregistrement d'un fichier.

Tout ce à quoi on peut s'attendre

Au-delà des spécifications et des hooks, Kiro inclut toutes les fonctionnalités attendues d'un éditeur de code d'IA : Support de Model Context Protocol (MCP) pour connecter des outils spécialisés, règles de pilotage pour guider le comportement de l'IA à travers un projet, et chat agentique pour des tâches de codage ad-hoc avec des fournisseurs de fichiers, d'URL, de contexte Doc's. Kiro est construit sur Code OSS, il est donc possible de conserver les paramètres de VS Code et les plugins compatibles avec Open VSX tout en travaillant avec l'EDI. Les développeurs bénéficient d'une expérience de codage IA complète, ainsi que des fondamentaux nécessaires à la production.

Alors qu'Amazon AWS vient de lancer Kiro, la promesse d'une productivité améliorée grâce à l'IA suscite un scepticisme croissant. Une récente étude menée par Model Evaluation & Threat Research a révélé que les outils de codage IA ralentissaient les développeurs tout en leur donnant l'illusion d'être plus rapides. Selon cette étude, les développeurs utilisant des outils d'IA mettent 19 % plus de temps à accomplir leurs tâches de codage, alors qu'ils s'attendaient à un gain de productivité de 24 %. Ces conclusions, ainsi que celles d'études précédentes faisant état d'un taux de bogues plus élevé lors de l'utilisation de ces outils, remettent en question les gains de productivité promis par l'IA.

Télécharger Kiro

Sources : Amazon Web Services, Kiro

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous qu'il s'agit d'une initiative crédible ou pertinente ?
Avez-vous déjà utilisé cet outil ou un outil similaire pour votre usage ou le développement d'applications, et si oui, qu'en pensez-vous ?

Voir aussi :

L'avenir du développement logiciel sera-t-il fait de «vibe coding» au lieu d'une connaissance technique ? Accepter un code écrit par l'IA sans en comprendre le fonctionnement devient de plus en plus populaire

Google lance Gemini CLI, un agent de codage libre et open source qui apporte l'IA à votre terminal, ce nouvel outil de vibe coding peut créer et modifier du code pour vous directement dans le terminal

"Vibe Coding" vs Réalité, par Cendyne

Vibe coding avec GitHub Copilot : Microsoft annonce que le mode agent et le support MCP sont disponibles dans les EDI JetBrains et Eclipse

[dfiad77pro]

Ils me font vraiment rire tous (windsurf, cursor...) , ben ils disent un nouvel IDE mais fork donc pompent 90% du code de vscode, résultat le gagnant reste Microsoft qui ont eu la bonne idée de créer VSCODE en libre. Résultat plus d'innovation coté IDE...

[antleg]

Ils me font vraiment rire tous (windsurf, cursor...) , ben ils disent un nouvel IDE mais fork donc pompent 90% du code de vscode, résultat le gagnant reste Microsoft qui ont eu la bonne idée de créer VSCODE en libre. Résultat plus d'innovation coté IDE...

https://jetbrains.developpez.com/act...lus-complexes/

L'innovation n'est pas morte, loin de là

[Stéphane le calme]

AWS paralysé 13 heures par son propre outil d'IA agentique : Kiro a supprimé un environnement AWS entier pour corriger un bug,
quand l'autonomie agentique devient un risque opérationnel de premier ordre

En décembre 2025, un outil d'IA développé en interne par Amazon a provoqué une panne de 13 heures sur AWS en décidant, de sa propre initiative, de supprimer et recréer l'environnement de production qu'il était censé corriger. Une mésaventure révélatrice des tensions entre la course à l'automatisation, le contrôle humain et la communication corporative — et qui pose des questions fondamentales sur le déploiement des agents IA en production.

L'histoire commence de façon banale : des ingénieurs d'Amazon Web Services confient à Kiro, le nouvel outil de développement agentique maison, la tâche de résoudre un problème mineur dans AWS Cost Explorer — le service qui permet aux clients de visualiser et gérer leurs dépenses cloud. Rien de dramatique en apparence. Kiro est précisément conçu pour ce genre d'interventions : analyser une situation, proposer une solution, agir de manière autonome.

Sauf que l'IA a fait quelque chose de plus... radical. Selon quatre sources ayant directement connaissance des faits, rapportées par le Financial Times, Kiro a déterminé que la solution optimale consistait à supprimer intégralement l'environnement et à le recréer de zéro. Résultat : 13 heures de panne. Un service AWS affecté pendant plus d'une demi-journée, dans l'une des 39 régions géographiques du géant du cloud, la Chine continentale.

Ce serait déjà suffisamment préoccupant pris isolément. Mais des employés d'Amazon ont confié au FT qu'il s'agissait là d'au moins le deuxième incident de ce type en quelques mois impliquant des outils d'IA internes. Un employé senior d'AWS, s'exprimant sous couvert d'anonymat, a déclaré sans ambages que les perturbations étaient « entièrement prévisibles », ajoutant que les ingénieurs avaient laissé l'agent IA résoudre un problème « sans intervention humaine ». Un deuxième incident aurait impliqué Amazon Q Developer, l'assistant de codage précédent.

La montée en puissance de Kiro et d'une culture de l'adoption forcée

Kiro n'est pas un projet expérimental confiné à un laboratoire de recherche. Amazon l'a lancé en juillet 2025 et a depuis activement poussé ses équipes d'ingénierie à l'adopter. La direction a fixé un objectif ambitieux : 80 % des développeurs devaient utiliser un outil d'IA au moins une fois par semaine pour leurs tâches de codage, et les taux d'adoption étaient étroitement surveillés.

C'est là que réside peut-être le vrai problème de fond. Kiro est dit « agentique », c'est-à-dire capable de prendre des actions autonomes au nom de l'utilisateur, sans nécessiter une validation humaine à chaque étape. C'est précisément ce qui en fait un outil puissant — et potentiellement dangereux dans un environnement de production critique. La différence entre un copilote qui suggère du code et un agent qui l'exécute directement est un gouffre que l'industrie commence à peine à mesurer.

Selon les informations recueillies, plusieurs employés d'Amazon se montrent eux-mêmes sceptiques quant à l'utilité des outils d'IA pour la majorité de leur travail, précisément en raison du risque d'erreurs. Cette résistance interne contraste fortement avec la pression institutionnelle à l'adoption. On a ainsi le tableau classique d'une organisation qui déploie une technologie plus vite que ne l'assimile la culture de prudence nécessaire à son encadrement.

La réponse d'Amazon, ou l'art du gaslighting corporatif

Face à l'onde de choc médiatique, AWS a publié un billet de blog au titre explicite : « Correcting the Financial Times report about AWS, Kiro, and AI » (Correction de l'article du Financial Times concernant AWS, Kiro et l'IA). Le ton est ferme, la posture défensive.

La thèse centrale d'Amazon se décline en trois axes. Premièrement, l'incident de décembre était « extrêmement limité » et ne concernait qu'un seul service dans une seule région, sans aucun client affecté visiblement. Deuxièmement, la société affirme que le problème découlait d'un rôle mal configuré — « le même problème qui pourrait survenir avec n'importe quel outil de développement, qu'il soit alimenté par l'IA ou non, ou avec une action manuelle. » Troisièmement, Amazon nie formellement l'existence d'un second incident ayant impacté AWS, qualifiant cette affirmation du FT de « totalement fausse ».

Amazon a également précisé que par défaut, l'outil Kiro « demande une autorisation avant d'entreprendre toute action », mais que l'ingénieur impliqué dans l'incident de décembre disposait de « permissions plus larges que prévu — un problème de contrôle d'accès utilisateur, pas un problème d'autonomie de l'IA. »

« L'incident survenu en décembre dernier était extrêmement limité et n'a affecté qu'un seul service (AWS Cost Explorer, qui permet aux clients de visualiser, comprendre et gérer les coûts et l'utilisation d'AWS au fil du temps) dans l'une de nos 39 régions géographiques à travers le monde. Il n'a eu aucun impact sur les ressources de calcul, de stockage, de base de données, les technologies d'IA, ni sur aucun autre des centaines de services que nous exploitons.

« Le problème provenait d'un rôle mal configuré, un problème qui peut survenir avec n'importe quel outil de développement (avec ou sans IA) ou suite à une action manuelle. Nous n'avons reçu aucune demande de renseignements de la part de nos clients concernant cette interruption. Nous avons mis en place de nombreuses mesures de protection pour éviter qu'un tel incident ne se reproduise, non pas parce qu'il a eu un impact important (il n'en a pas eu), mais parce que nous tenons à tirer les leçons de notre expérience opérationnelle afin d'améliorer notre sécurité et notre résilience.

« Parmi ces mesures figure un audit par les pairs obligatoire pour l'accès à la production. Bien que des incidents opérationnels liés à des contrôles d'accès mal configurés puissent se produire avec n'importe quel outil de développement (avec ou sans IA), nous estimons qu'il est essentiel d'en tirer des enseignements. L'affirmation du Financial Times selon laquelle un second incident aurait affecté AWS est totalement fausse. »

La formule est habile. Mais elle soulève une question que tout architecte système chevronné posera immédiatement : si un outil agentique peut supprimer un environnement de production entier parce qu'un ingénieur avait des droits trop larges, n'est-ce pas précisément le genre de scénario catastrophe que les garde-fous de l'outil auraient dû prévenir ? La configuration de l'accès humain ne devrait pas être le seul verrou de sécurité d'un système capable d'actions destructrices irréversibles.

La distinction entre « erreur utilisateur » et « erreur IA » est par ailleurs philosophiquement contestable dans ce contexte. L'agent a pris une décision — supprimer un environnement entier — qui, même si elle était techniquement dans le périmètre de ses permissions, était manifestement disproportionnée par rapport à la tâche assignée. Un développeur humain avec les mêmes droits d'accès aurait-il pris la même décision ? C'est peu probable. C'est précisément là que la distinction « c'est la même chose qu'avec n'importe quel outil » s'effondre.

Le paradoxe de l'IA qui vend de l'IA

La dimension stratégique de cet épisode pour Amazon est considérable. AWS a généré 35,6 milliards de dollars de revenus au dernier trimestre, en hausse de 24%, avec 12,5 milliards de bénéfices opérationnels. Une bonne part de cette croissance est portée par les services d'IA — et Amazon vend activement des outils agentiques à ses propres clients AWS. Tout récit impliquant une IA causant des pannes dans ses propres datacenters est donc doublement indésirable : il fragilise à la fois l'image opérationnelle d'AWS et la crédibilité commerciale de ses offres d'IA.

C'est ce qui rend la communication d'Amazon si symptomatique. Reconnaître une quelconque responsabilité de l'IA serait admettre que les outils vendus aux clients pourraient présenter les mêmes risques. La ligne de défense "erreur humaine" n'est pas seulement un réflexe d'auto-protection : c'est une nécessité commerciale.

Mais à trop minimiser, on crée un autre problème. Les employés qui ont témoigné auprès du FT ne sont pas des observateurs extérieurs — ce sont des ingénieurs seniors qui vivent quotidiennement avec ces outils. Leur avertissement que les pannes étaient "entièrement prévisibles" mérite d'être pris au sérieux, indépendamment de la position officielle de l'entreprise.

La question des garde-fous agentiques, le vrai sujet

Au-delà du cas particulier d'Amazon, cet incident cristallise un défi que toute l'industrie affronte en ce moment : comment intégrer des agents IA autonomes dans des environnements de production critiques sans créer de nouveaux vecteurs de risque systémique ?

Les LLM et les agents qui les utilisent raisonnent différemment d'un être humain. Là où un ingénieur expérimenté applique des heuristiques de prudence — « supprimer un environnement entier pour corriger un bug mineur, c'est disproportionné » — un agent optimise selon les métriques de sa tâche sans disposer nécessairement du contexte culturel et opérationnel qui rendrait cette décision absurde. Il n'a pas peur de se tromper. Il n'a pas de mémoire des catastrophes passées. Il a des droits d'accès et un objectif.

C'est pourquoi la réponse d'Amazon — implémenter une revue obligatoire par les pairs pour les accès en production — est la bonne direction, même si elle est présentée comme une mesure de bon sens. Elle remet l'humain dans la boucle pour les décisions à fort impact. C'est exactement ce que préconisent les meilleures pratiques d'architecture agentique : des checkpoints humains proportionnels à la criticité et à l'irréversibilité des actions.

La séquence expose un risque familier : un agent automatisé prenant des décisions radicales sans garde-fous humains effectifs ni contraintes conservatrices. À l'échelle à laquelle AWS opère, même une seule action automatisée mal calibrée peut se propager en cascade, affectant clients et services tiers qui dépendent de l'infrastructure cloud.

Ce que cela dit de notre rapport à l'automatisation

La tentation est grande, pour les organisations déployant des outils d'IA, de traiter leur adoption comme un indicateur de maturité technologique. Amazon l'a fait en fixant des objectifs de taux d'adoption. C'est une erreur de gouvernance classique : confondre l'usage d'un outil avec la maîtrise de cet outil.

Les agents IA de nouvelle génération — Kiro, GitHub Copilot Workspace, les divers agents de codage autonomes qui prolifèrent — représentent une rupture qualitative par rapport aux assistants génératifs classiques. Ils n'assistent plus : ils agissent. Et cette transition exige des organisations qu'elles repensent en profondeur leurs modèles de gouvernance, de permissions, de validation et d'audit.

L'incident AWS n'est probablement pas le dernier du genre. D'autres entreprises, moins bien équipées qu'Amazon en matière de résilience et de capacité de récupération, traverseront des épisodes similaires. La question n'est pas de savoir si les agents IA feront des erreurs — ils en feront. La question est de savoir si les systèmes qui les entourent sont conçus pour que ces erreurs restent contenables et réversibles.

C'est là le vrai enseignement de l'affaire Kiro : non pas qu'une IA ait "mal agi", mais que l'architecture de confiance autour d'elle n'était pas à la hauteur de son autonomie.

Sources : Amazon, Financial Times

Et vous ?

Quelle lecture faites-vous de la réponse d'AWS ?

La distinction entre « erreur IA » et « erreur utilisateur » vous semble-t-elle pertinente ou rhétorique dans le cas d'un agent autonome disposant de droits d'accès larges ? Qui porte la responsabilité réelle ?

Les objectifs de taux d'adoption imposés aux équipes de développement (80 % chez Amazon) vous paraissent-ils compatibles avec une intégration prudente et maîtrisée des outils agentiques ?

Faut-il imposer une forme de « principe de proportionnalité » aux agents IA en production — leur interdire contractuellement les actions dont la portée dépasse largement l'objectif assigné ?

Amazon vend les mêmes outils agentiques à ses clients AWS qu'il utilise en interne. Cela change-t-il votre perception du niveau de confiance à accorder à ces offres commerciales ?

Voir aussi :

L'avenir du développement logiciel sera-t-il fait de «vibe coding» au lieu d'une connaissance technique ? Accepter un code écrit par l'IA sans en comprendre le fonctionnement devient de plus en plus populaire

Google lance Gemini CLI, un agent de codage libre et open source qui apporte l'IA à votre terminal, ce nouvel outil de vibe coding peut créer et modifier du code pour vous directement dans le terminal

"Vibe Coding" vs Réalité, par Cendyne

Vibe coding avec GitHub Copilot : Microsoft annonce que le mode agent et le support MCP sont disponibles dans les EDI JetBrains et Eclipse

[Anselme45]

Mais pourquoi s'étonner de cette erreur de l'IA?

Ce ne sont pas les promoteurs de l'IA qui crient sur tous les tons "L'IA est supérieure à l'être humain dans tous les domaines!!!!!"

Quand on dit "Tous les domaines", c'est "Tous les domaines" y compris dans les erreurs de manipulations qui mettent à genou un cloud

[jnspunk]

Il y a un épisode des Simpson où Homer fait du télétravail pour gérer la centrale nucléaire, et comme il en a marre de toujours appuyer sur la touche Y (yes) pour confirmer, il utilise un oiseau mécanique pour appuyer sur la touche de manière autonome. Évidemment, ça provoque une catastrophe.
Ce qui me fait rire, c'est le parallèle avec cette news : quand Homer rejette la faute sur l'oiseau automate en lui disant "Je te faisais confiance !", on critique l'IA mais pas la personne qui l’utilise, c’est désolant.

[kain_tn]

Il y a un épisode des Simpson où Homer fait du télétravail pour gérer la centrale nucléaire, et comme il en a marre de toujours appuyer sur la touche Y (yes) pour confirmer, il utilise un oiseau mécanique pour appuyer sur la touche de manière autonome. Évidemment, ça provoque une catastrophe.
Ce qui me fait rire, c'est le parallèle avec cette news : quand Homer rejette la faute sur l'oiseau automate en lui disant "Je te faisais confiance !", on critique l'IA mais pas la personne qui l’utilise, c’est désolant.

Tout à fait, mais il y a une différence avec le monde réel: chez Amazon, c'est un peu comme si Mr Burns forcait Homer à utiliser l'oiseau à bascule.
Et le prétexte de Mr Burns serait que l'oiseau à bascule est tout à fait qualifié pour ce genre de travail et fera économiser de l'argent.
C'est ce qui se passe actuellement, dans toutes les GAFAM. Amazon n'est pas un cas isolé.

[gabi7756]

Bientôt il faudra une IA pour faire la connerie ( implémenter un truc), une IA vérifier que ca pète pas ( bah si) et une IA pour corriger le bug ( pour encore tout péter).

Résultat : l'anarchie

Ils sont fort pour faire du marketting sur l'IA ...

C'est désolant que ca fonctionne ...
Bientôt on sera étonné qu'un humain connaissent ses tables de multiplications

[OuftiBoy]

à tous,

Je partage tout à fait cette remarque de kain_tn :

Tout à fait, mais il y a une différence avec le monde réel: chez Amazon, c'est un peu comme si Mr Burns forcait Homer à utiliser l'oiseau à bascule. Et le prétexte de Mr Burns serait que l'oiseau à bascule est tout à fait qualifié pour ce genre de travail et fera économiser de l'argent. C'est ce qui se passe actuellement, dans toutes les GAFAM. Amazon n'est pas un cas isolé.

L'IA n'est pas "fiable" assez que pour la laisser agir seule. Il faut une compétence humaine pour vérifier. Entre les "Hallucinations", les "Décisions" qu'on veut qu'elle prenne seule (via des agents), la pression mise sur des équipes obligée/forcée d'utiliser l'IA, et le fait que le ROI ne soit visiblement pas encore là, il y a de quoi douter d'un avenir radieux, surtout pour les "investisseurs" qui ne savent plus quoi penser.

Quand le "doute" s'installe sur une technologie, ce n'est pas bon signe...

L'IA n'a rien d'intelligent que le nom, le reste, c'est du traitement de donnée, avec statistiquement un pourcentage de bon ou de mauvais résultat. Certes, elle peut offrir un gain, mais c'est difficile de se positionner, avec des news soit dithyrambiques soit catastrophiques et vice et versa...

Actuellement, l'utilisation de l'IA ne semble pas apporter les gains espérés, et il est difficile de dire si la situation va s'améliorer à court/moyen/long terme. Certains pourront faire le gros dos et "attendre", mais d'autres n'auront pas ce luxe.

L'IA est clivante, car si elle ne fonctionne pas plus "correctement" d'ici quelques temps, cela aura été un immense gâchis de ressources.

L'IA est clivante car si elle fonctionne, elle va déréguler trop rapidement tout un tas d'entreprises et de métiers, et il n'y aura plus personne pouvant se la payer et/ou les investisseurs vont la jouer plus prudente alors qu'il faudrait de l'investissement ailleurs.

L'IA est clivante car elle remet en cause des "métiers" dont on a cruellement besoin, et que tout le battage médiatique autours d'elle va décourager la formation de jeunes développeurs.

Et si l'IA réalise ce qu'elle promet, on va droit vers l'idiocratie, et je ne pense pas que ce soit une bonne chose...

De plus, elle fait grimper le prix de composants et le coût de l'électricité pour tout le monde, pas seulement pour ceux qui l'utilise, et ça la fout mal. Tout un tas de produit vont voir leut prix indirectement augmenter, et au final, c'est les consommateurs "Mr et Md michu" (nous) qui vont trinquer et payer l'ardoise, indirectement certes, mais réellement.

L'un dans l'autres, à de rares exceptions près, l'IA est néfastes pour une grosse majorité.

Ce n'est que mon avis, chacun a le sien.

BàV et Peace & Love.

[Anselme45]

Bientôt il faudra une IA pour faire la connerie ( implémenter un truc), une IA vérifier que ca pète pas ( bah si) et une IA pour corriger le bug ( pour encore tout péter).

Et enfin une centaine d'êtres humains pour identifier les conneries des IA et les corriger

[ChristianRoberge]

Un humain n'est pas à l'abri d'une telle erreur. C'est déjà arrivé dans le passé. Il y a une différence majeur avec l'IA car elle ne s'aperçoit pas de son erreur et un humain doit intervenir pour tout réparer. C'est ici que le bas blesse:

1- L'intervention humaine est plus complexe que d'habitude car l'humain n'a pas a priori d'idée sur ce qui a été fait et pourquoi il y a un problème généré par l'IA. Quand, il y a un problème d'origine humaine, l'humain sait instantanément la source du problème car c'est lui-même qui l'a généré.

2- L'humain DOIT faire confiance à l'IA. C'est une condition préalable au travail avec cet outil. Dans le cas contraire, il n'utilisera pas l'IA.

3- L'humain est mis en confiance avec l'IA car à part les cas extrême décrit ci-dessus, le travail semble satisfaisant. L'humain laisse alors tomber les vérifications minutieuses du travail de l'IA. De toute façon, un vérification minutieuse prendrait au moins le même temps, voire plus, qu'avoir fait le travail soi-même.

4- Le cumul de petits problèmes liées à l'IA peuvent devenir catastrophiques (Sécurité, performance, etc.). L'intervention humaine peut corriger ces petits problèmes s'il sont détectés mais selon certain test sur la génération de code, l'IA a tendance a réintroduire le même problème. Alors comment peut-on corriger quand l'IA est toujours présent?

Le constat est clair, l'IA argentique n'est qu'un mirage, une illusion. L'argentique est un idéal fantastique à atteindre mais c'est ne pas pour ce siècle! Aucune technologie actuelle, des variantes ou améliorations importantes ne pourra atteindre cet objectif. Plusieurs PDG disent que c'est une question d'année, je les comprends, il faut encourager l'illusion pour continuer à amasser des milliards d'investissement.

[floyer]

Sur un fil de discussion, j’évoquais la nécessité de poser des garde-fous autour de l’IA (sandboxing)… on me répondait que je n’avais rien compris, que cela briderait le potentiel de l’IA argentique.

Si c’est ça le potentiel de l’IA agentique…

Que l’on concentre l’IA sur des tâches sans risques (audit de code, et - soyons ambitieux - génération d’élément de preuve de conformité, comme pour l’automatisation de la ligne de métro Meteor). Pour l’agentique sans limite, cela sera sans moi.

[jnspunk]

Tout à fait, mais il y a une différence avec le monde réel: chez Amazon, c'est un peu comme si Mr Burns forcait Homer à utiliser l'oiseau à bascule.
Et le prétexte de Mr Burns serait que l'oiseau à bascule est tout à fait qualifié pour ce genre de travail et fera économiser de l'argent.
C'est ce qui se passe actuellement, dans toutes les GAFAM. Amazon n'est pas un cas isolé.

En fait le fond de mon message, c’était de dire qu’on critique l'IA pas l’humain qui s’en sert. Or dans ton histoire ce sont toujours des humains qui forcent d’autres humains à utiliser l’IA. Du coup il n’y a aucune différence fondamentale avec l’histoire de base. 

[OuftiBoy]

jnspunk,

En fait le fond de mon message, c’était de dire qu’on critique l'IA pas l’humain qui s’en sert. Or dans ton histoire ce sont toujours des humains qui forcent d’autres humains à utiliser l’IA. Du coup il n’y a aucune différence fondamentale avec l’histoire de base. 

Si, il y'a une grosse différence. L'humain SAIT qu'il est faible, et tente de mettre en place des "gardes-fous" et des "procédures" pour diminuer le risque d'erreur. L'IA ne sait rien d'elle-même, ce n'est pas un être vivant qui respire et réfléchit.

Le second point, c'est que l'on accepte l'erreur humaine, car L'ERREUR EST humaine. On n'acceptera pas la même erreur provenant d'une machine. Un bête exemple, les jouets pour enfant sont contrôlés bien avant leur mise sur le marché. Et si plus de 2 enfants s'étranglent avec l’œil d'une simple peluche qui peut se détacher trop facilement, le producteur de ce produit devra rendre des comptes, et revoir sa copie s'il veut ré-introduire son produit.

Tout cela n'est pas parfait, et des jouets passent entre les mailles du filet sécuritaire, mais on peut le détecter et agir en conséquence.

Avec L'IA "agentique", c'est comme laisser entrer n'importe toi et vendre n'importe quoi n'importe comment...

Avant, on disait que les problèmes informatiques résultaient plus d'erreur d'humain l'utilisant mal, il va y avoir maintenant 2 responsables l'agent et l'humain,
qui ne peut que produire plus d'erreurs. Donner à des humains (ou les forcer) a utiliser un agent qu'il ne sont pas capables de maîtriser, n'est pas une bonne idée, selon mon petit avis. En plus, sera ne sera pas un agent, mais des agents qui vont venir se glisser entre l'ordinateur et son utilisateur, qui risque d'être vite perdu devant le capharnaüm que cette pratique va créer.

C'est comme de dire qu'un humain doit connaître le fonctionnement d'un moteur pour pouvoir conduire une voiture... cela n'est pas réaliste.

BàV et Peace & Love.

[vertex.3F]

Avant, on disait que les problèmes informatiques résultaient plus d'erreur d'humain l'utilisant mal, il va y avoir maintenant 2 responsables l'agent et l'humain,

Bonjour, pour moi il n'y a toujours eu qu'un seul responsable : l'humain

(l'informatique dans son ensemble est sa construction, pour ne pas dire "son œuvre" )

un humain doit connaître le fonctionnement d'un moteur pour pouvoir conduire une voiture... cela n'est pas réaliste.

Je suis parfaitement aligné avec cela.

L'utilisateur de l'IA ne l'a pas entraînée et ajustée, il n'a pas forcément la connaissance des composants internes ni de la théorie sur laquelle tout cela s'appuie. En quelque sorte une fois qu'il a choisi un modèle il subit obtient un résultat magique qu'il tente progressivement d'affiner avec son petit prompt et parfois quelques petits paramètres qui sont mis à sa disposition. L'utilisateur ne pense pas au data poisening ni au model collapse qui menacent son outil.

Sur le terrain, en entreprise, les croyances et illusions démesurées autour des gains de productivité sont en train de faire place aux constats raisonnables.

Au passage je partage un lien sur le fond que je trouve très riche : https://www.duperrin.com/2025/05/26/...erative-bulle/

[Stéphane le calme]

Suite à des pannes, Amazon exigera la validation des modifications assistées par l'IA par ses ingénieurs seniors :
AWS a subi au moins deux incidents liés à l'utilisation d'assistants de codage IA

Depuis plusieurs mois, la plateforme e-commerce d'Amazon accumule les incidents graves. Des pannes à répétition, dont au moins une directement liée à l'usage d'outils de codage assistés par IA, ont poussé la direction à convoquer en urgence une réunion interne et à revoir en profondeur ses pratiques de déploiement. En filigrane, se dessine un paradoxe vertigineux : le géant qui vend l'IA au monde entier se retrouve à en payer le prix fort sur sa propre infrastructure.

Début mars 2026, pendant près de six heures, le site Amazon.com et son application mobile sont devenus inaccessibles pour une partie significative des utilisateurs. Impossible de passer commande, de consulter son compte, d'afficher les prix. Officiellement, Amazon a invoqué une mise à jour logicielle défaillante comme cause de l'incident. Officieusement, c'est une autre histoire que racontent les documents internes.

Selon le Financial Times, qui a eu accès à une note de briefing interne, Amazon a lui-même décrit une « tendance aux incidents » caractérisée par un « rayon d'explosion élevé » (high blast radius) et des « changements assistés par GenAI ». Parmi les facteurs qui y ont contribué figurait explicitement « l'usage nouveau de la GenAI, pour lequel les meilleures pratiques et les garde-fous ne sont pas encore pleinement établis ».

Une réunion de crise en mode TWiST

Dave Treadwell, le vice-président senior en charge des fondations techniques du site Amazon, a écrit à ses équipes : « Comme vous le savez probablement, la disponibilité du site et de l'infrastructure associée n'a pas été bonne récemment. » Il a convoqué une réunion TWiST (This Week in Stores Tech), qui est habituellement facultative, en la rendant obligatoire, pour effectuer une plongée en profondeur sur « certains des problèmes qui nous ont conduits là ».

Ce TWiST d'urgence a débouché sur une mesure immédiate : les modifications de code assistées par IA devront désormais être approuvées par des ingénieurs seniors avant tout déploiement. Une décision qui, pour beaucoup d'observateurs, relève du bon sens le plus élémentaire — et qui soulève des questions bien plus profondes sur les pratiques qui ont rendu cette mesure nécessaire.

Un historique qui s'alourdit

Cette panne de mars n'est pas un accident isolé. Elle s'inscrit dans une série d'incidents qui remonte au moins à la fin 2025. En décembre 2025, un incident impliquant l'outil de codage agentique Kiro, un EDI développé en interne chez Amazon pour automatiser ou accélérer les modifications de code, avait provoqué treize heures d'indisponibilité d'une fonctionnalité de gestion des coûts AWS. Selon des témoignages internes, des ingénieurs avaient laissé l'agent IA résoudre des problèmes sans intervention humaine, ce qui aurait conduit l'outil à « supprimer et recréer l'environnement ».

Face à ces révélations, Amazon avait alors adopté des garde-fous : revue entre pairs obligatoire pour les accès en production, formations internes. La panne de mars 2026 montre que ces mesures n'ont pas suffi.

À chaque incident, Amazon a maintenu la même ligne de défense. En février, après un incident affectant AWS Cost Explorer dans la partition Chine continentale, un porte-parole déclarait : « Nous n'avons pas constaté de preuves convaincantes que les incidents sont plus fréquents avec les outils IA. » Interrogé à nouveau par The Register après les révélations du FT, Amazon a confirmé que cette position restait inchangée, sans pour autant fournir les données qui permettraient une analyse indépendante.

Corey Quinn, chief cloud economist chez Duckbill, avait résumé l'absurdité de la situation avec une formule percutante : « AWS préfèrerait que le monde croie que ses ingénieurs sont incompétents plutôt qu'admettre que son intelligence artificielle a fait une erreur. »

Le piège des suppressions de postes en cascade

Pour comprendre ce qui se joue réellement chez Amazon, il faut remonter plus loin. Le géant a licencié des dizaines de milliers d'employés depuis 2022, dont 16 000 travailleurs dans sa dernière vague de janvier 2026, tout en annonçant simultanément un investissement prévu de 200 milliards de dollars en dépenses d'infrastructure pour l'année. La logique est simple sur le papier : moins d'humains, plus d'IA, même output. Voire plus.

Le problème, c'est que cette équation s'est révélée fausse sur le terrain. Avec moins d'ingénieurs pour effectuer le même volume de travail, la direction a contraint les équipes restantes à utiliser des outils de codage IA pour accélérer leur production. Mais le code généré par IA exige en retour une relecture humaine rigoureuse, relecture que des équipes réduites n'ont pas forcément la capacité ni le temps d'effectuer.

James Gosling, le créateur du langage Java et ancien ingénieur distingué chez AWS jusqu'en 2024, avait anticipé cette dynamique catastrophique. Dans un post LinkedIn publié après la grande panne AWS d'octobre 2025, il écrivait : « Quand l'explosion de l'IA s'est produite et que j'étais encore chez AWS, j'ai été stupéfait de voir comment la structure de l'entreprise a été tordue, et comment des équipes ont été démolies. L'analyse du retour sur investissement était d'une myopie désastreuse. Ces systèmes sont des structures complexes et interconnectées. »

Le code « résistant à la revue »

Au-delà du contexte organisationnel, c'est la nature même du code produit par les LLM qui pose problème. Les développeurs expérimentés qui s'y sont confrontés en production décrivent un phénomène préoccupant : le code IA est superficiellement convaincant, syntaxiquement impeccable, mais truffé d'erreurs logiques non évidentes que même un reviewer attentif peut laisser passer.

Un développeur a ainsi résumé le problème : les LLM génèrent des tokens qui « ont l'air corrects ». Le code junior humain est repérable à distance par un senior. Le code IA, lui, lit comme s'il sait ce qu'il fait, jusqu'à ce qu'on creuse et qu'on découvre des erreurs fondamentales dissimulées sous une couche de fluidité rassurante. D'autres praticiens pointaient un problème de volume : l'IA produit des masses de code en un temps infime, au-delà de ce qu'un reviewer humain peut absorber de manière sérieuse.

Des plateformes tierces de revue de code rapportent par ailleurs que, sur des centaines de pull requests analysées, le code généré par IA présente 1,7 fois plus de problèmes que le code humain. Un écart significatif, qui ne va pas dans le sens du discours dominant.

Le paradoxe de Microsoft aussi

Amazon n'est pas seul dans cette situation. Microsoft a annoncé fin janvier 2026 qu'il travaillait à corriger de nombreux défauts de Windows 11 et à restaurer sa réputation, neuf mois après que le PDG Satya Nadella avait déclaré que l'IA rédigeait jusqu'à 30 % du code de l'entreprise, certains projets étant entièrement codés par IA. La temporalité est éloquente.

Ce n'est pas un hasard si les deux plus grands vendeurs d'infrastructure cloud au monde se retrouvent à essuyer des incidents liés à leurs propres pratiques de codage IA. Les deux ont massivement réduit leurs effectifs d'ingénierie tout en déployant des outils génératifs en production. Les deux ont communiqué sur les gains de productivité. Et les deux récoltent désormais les conséquences d'une adoption précipitée, sans que les pratiques de sécurité aient suivi le rythme.

Une réponse au symptôme, pas à la cause

La mesure prise par Amazon, imposer une validation par un ingénieur senior sur tout code assisté par IA, est présentée comme une avancée. Elle l'est, formellement. Mais plusieurs voix du secteur soulèvent une objection structurelle : si l'on a licencié massivement des juniors pour les remplacer par de l'IA, et que l'IA produit du code difficile à relire, au point d'accaparer l'intégralité du temps disponible des seniors... qui va relire ce code ?

La question de la formation des futurs ingénieurs seniors n'est pas anodine non plus. Les juniors apprennent leur métier en écrivant du code, en faisant des erreurs, en recevant des retours. Un système où l'IA génère l'essentiel du code et où les juniors ne font que valider sans comprendre n'est pas un système qui crée de l'expertise... c'est un système qui l'érode.

Amazon s'est retrouvé à réapprendre à la dure une leçon que l'ingénierie connaît depuis longtemps : la supervision humaine n'est pas un coût à éliminer. C'est une fonction critique. Quand on la sous-dimensionne dans la précipitation, c'est l'infrastructure entière qui finit par en payer le prix et avec elle, les clients dont les commandes disparaissent pendant six heures.

Source : FT

Et vous ?

La revue obligatoire par un senior est-elle une réponse suffisante, ou Amazon ne fait-il que déplacer le problème sans résoudre la tension fondamentale entre réduction d'effectifs et exigences de qualité ?

Le code généré par IA est-il intrinsèquement plus difficile à relire que le code humain, ou est-ce une question de maturité des pratiques qui s'améliorera avec le temps ?

Amazon a systématiquement nié tout lien entre ses pannes et l'IA, tout en prenant des mesures correctives ciblant précisément l'IA : comment interpréter cette contradiction de communication ?

Si les seniors sont surchargés par la relecture du code IA, comment les entreprises vont-elles former la prochaine génération d'ingénieurs expérimentés ?

L'industrie tech a-t-elle sous-estimé le coût réel du « vibe coding » en production, comparé aux économies réalisées sur les effectifs ?

Voir aussi :

L'avenir du développement logiciel sera-t-il fait de «vibe coding» au lieu d'une connaissance technique ? Accepter un code écrit par l'IA sans en comprendre le fonctionnement devient de plus en plus populaire

Google lance Gemini CLI, un agent de codage libre et open source qui apporte l'IA à votre terminal, ce nouvel outil de vibe coding peut créer et modifier du code pour vous directement dans le terminal

"Vibe Coding" vs Réalité, par Cendyne

Vibe coding avec GitHub Copilot : Microsoft annonce que le mode agent et le support MCP sont disponibles dans les EDI JetBrains et Eclipse

[kain_tn]

La revue obligatoire par un senior est-elle une réponse suffisante, ou Amazon ne fait-il que déplacer le problème sans résoudre la tension fondamentale entre réduction d'effectifs et exigences de qualité ?

Bien sûr qu'on déplace la responsabilité: on a d'un côté des personnes peu qualifiées qu'on déresponsabilise et à qui on fournit un générateur, et de l'autre côté des personnes très qualifiées qu'on noie sous la responsabilité, en leur demandant d'être responsables de la qualité des montagnes d'excréments générés par les premiers.

La réalité, c'est qu'il s'agit de l'entêtement de toute cette caste de management incompétent à persister dans leurs mauvais choix et à ne pas reconnaître leurs erreurs.

Le code généré par IA est-il intrinsèquement plus difficile à relire que le code humain, ou est-ce une question de maturité des pratiques qui s'améliorera avec le temps ?

Non seulement il est inutilement verbeux mais en plus le rapport entre la génération et la relecture est déséquilibré: un développeur qui "vibe-code" peut générer des millions de lignes de code en peu de temps - l'humain qui doit faire la relecture derrière s'en retrouve submergé.

Amazon a systématiquement nié tout lien entre ses pannes et l'IA, tout en prenant des mesures correctives ciblant précisément l'IA : comment interpréter cette contradiction de communication ?

C'est un secret de polichinelle. Tout le monde sait d'où vient le problème, dans le milieu, car les gens parlent.

Si les seniors sont surchargés par la relecture du code IA, comment les entreprises vont-elles former la prochaine génération d'ingénieurs expérimentés ?

Elles ne le feront pas. Des entreprises comme Amazon espèrent que leur IA sera suffisamment performante pour se passer des développeurs seniors, lorsque le problème se posera.

L'industrie tech a-t-elle sous-estimé le coût réel du « vibe coding » en production, comparé aux économies réalisées sur les effectifs ?

L'industrie de la tech, non: l'industrie de la finance, oui. Car c'est bien de ça qu'il s'agit: ces grandes boites sont gouvernées par des financiers qui appliquent tous les mêmes méthodes, indépendamment de leurs résultats ou du métier dans lequel ils évoluent.

[OuftiBoy]

à tous,

Je me demande combien de temps va "tenir" ce double discours des GAFAM. Ils se vantent de virer en masse des développeurs qualifiés, les remplaçant par des Agents IA et/ou des "juniors" bon marché, disent que 30% de leur code est "générer" par l'IA, et bien que les catastrophes se multiplient, ce n'est pas "à cause de l'IA". Qui a générer ces 30% alors ?

L'IA (dans le domaine du développement), ne semble pas tenir ses promesses, mais qui est étonné ? Du code, ça ne se "génère pas", ça se "construit". Comment espérer avoir un résultat correcte alors que les données d'entraînement se sont pas validées ? L'IA ne peut (en l'état actuel) n'aider que dans un "domaine" bien délimité, un peu comme les voitures "autonomes" :-)

Ce "code généré", même s'il est fonctionnelle, n'est ni optimal, ni facilement compréhensible, et c'est tout à fait normal. Lorsque vous arrivez dans une entreprise, et qu'on vous demande de "maîtriser" un code écrit pendant des années, il est déjà difficile de comprendre cette "base de code", alors du code copier/coller "généré" par une IA, ça ne doit pas être simple, et vu que le code est générer à la pelle, le comprendre, le "surveiller", le "mettre à jour", ça doit vite devenir un cauchemar. Surtout qu'en ayant viré les seniors, il ne pas grand monde de compétent pour gérer tout cela.

Et les "PDG" de la Tech devraient, au lieu de nous livrer leur discours "corporate/marketing", se mettre en mode "sourdine", et reprendre le contrôle de leurs entreprises...

Les soucis de Windows 11 n'arrivent pas maintenant par hasard. Il n'y rien que de ne pas voir, et reconnaître, qu'ont a "peut-être" été "trop vite" sur certaines choses...

Je ne sais pas qui a dis ici (ou dans un autre fil de discussion), que c'était "impossible" pour Microsoft de "tester" toutes les combinaisons "possibles" tant les combinaisons sont nombreuses. Je ne suis pas d'accord avec ce genre de raisonnement. Si un livre un "produit", sans l'avoir tester sur ce sur quoi il "devrait fonctionner", ce n'est pas acceptable. Il faut alors limiter ce qui est "supporté".

Je n'ai jamais été un "fan" d'Apple, mais ils ne semblent pas souffrir de ces problèmes. Sûrement car ils maîtrisent la chaîne complète, du hardware jusqu'aux applications.

C'est pour ça que j'ai pris l'analogie avec les "voitures" autonomes. Autonome jusqu'à un certains point, sur certaines "routes". J'attend toujours de voir une voiture "autonome" se faufiler dans les petites rues de mon village...

Enfin, si un système comme linux, avec des contributeurs venant de partout, arrive a "tenir" la route, et est maintenant devenu "mature" pour en tout cas Monsieur et Madame tout le monde (reste le soucis des applications métiers). Windows semble lui suivre le chemin inverse, depuis XP et Windows 2000, le système semble se dégrader de plus en plus (peut-être au fur à mesure que les seniors se retirent ? - chuuut, faut pas dire ça...).

Je suis passé depuis qlq mois sur Zorin OS, et j'y ai trouvé un "refuge" après 2 ou 3 jours d'adaptation. Je ne voudrais pas revenir en arrière. Rien n'est parfait, mais c'est nettement plus agréable... Le "système" ne change pas tout pendant une 'mise à jour', l'UI est stable, je n'ai recours à la ligne de commande que quand je le décide, car parfois, une ligne de commande est plus adapté qu'un clicodrôme pour certaines tâches.

Ma machine jugée dépassée par Microsoft (elle a 6 ans), tourne bien mieux sous linux (tout va plus vite) que sous Win10.

Ce n'est que ma modeste opinion sur ce qu'il se passe pour le moment. Chacun a son avis.

Bon, je retourne de suite sur le développement de mon petit compilateur pour mon petit langage.
BàV et Peace & Love.