Comment utiliser Claude comme architecte logiciel : le guide du Skill Viktor

Updated
Skill · .md

Le Skill à l'origine de ce guide : Viktor - Software Architect AI Skill. Il prend en compte ce que vous exécutez déjà, ce que vous ne pouvez pas modifier et les décisions que vous avez déjà prises, afin que les options arrivent filtrées par votre système réel plutôt que par un terrain vierge - 29 $, un seul paiement, à vous pour toujours.

Voir le Skill Viktor →

Une architecture est une liste de choses que vous avez décidé de ne plus pouvoir faire. Un modèle ne vous dira jamais que ce qu'une conception peut faire. Il n'est pas malhonnête : les documents sur lesquels il a été entraîné ont été écrits par des personnes décrivant des systèmes qui fonctionnaient, à une échelle qui justifiait qu'on en parle, et personne ne publie d'article sur le monolithe banal qui fonctionne toujours très bien. Le résultat est donc toujours conçu pour un terrain vierge et toujours maximal - le système au pic que vous avez imaginé, sur un terrain vierge, en laissant de côté les saisies.

Deux échecs, une seule cause

Presque toutes les réponses d'architecture inutiles remontent à la même cause : le corpus traite du problème intéressant, écrit par des personnes qui y ont été confrontées.

Il conçoit sur un terrain vierge. Une véritable architecture est presque toujours une évolution d'un système existant, menée par des personnes qui existent et reliée à des éléments auxquels vous n'avez pas le droit de toucher. Demandez la conception et vous en obtenez une qui suppose que rien de tout cela n'existe ; or les erreurs les plus coûteuses dans ce domaine ne consistent pas à choisir la mauvaise base de données - elles consistent à concevoir comme si une contrainte n'existait pas.

Il conçoit pour le pic. Architecture événementielle, un service par domaine, une file d'attente entre chaque paire de composants, Kubernetes en dessous. Ces choix ne sont pas mauvais. Ce sont les comptes rendus d'organisations qui en avaient besoin, et il n'existe aucun compte rendu des entreprises qui s'en sont bien sorties sans eux. La moyenne de la littérature produit donc une architecture pour une entreprise plus grande que la vôtre.

Les deux sont corrigeables, et aucun ne l'est en posant de meilleures questions sur la conception. Vous les corrigez en modifiant ce que le modèle est autorisé à supposer.

Les boîtes sont la partie facile

Demandez une architecture et vous obtenez des boîtes et des flèches. Les boîtes sont presque gratuites : un service qui fait clairement une seule chose est un problème résolu, et tout le monde peut se le représenter.

Toute la difficulté réside dans les flèches. Une flèche entre deux boîtes affirme que ces deux éléments peuvent communiquer, mais le diagramme ne justifie jamais cette affirmation. L'appel est-il synchrone et, dans ce cas, que fait l'appelant pendant les deux cents millisecondes où il attend ? Que se passe-t-il en cas d'échec - nouvelle tentative, et si oui l'opération est-elle idempotente, ou une nouvelle tentative débite-t-elle la carte deux fois ? Quel est le délai d'expiration et que se passe-t-il après ? L'ordre a-t-il de l'importance et quelque chose le garantit-il ? Si cette flèche est hors service pendant une heure, qu'est-ce qui continue de fonctionner et qu'est-ce qui ne fonctionne plus ?

Un diagramme ne répond à aucune de ces questions, et un modèle en générera tout de même un magnifique, parce que les diagrammes sont un genre et qu'il en a lu des milliers. Interrogez les flèches, et la conception change généralement. Souvent, elle se réduit à moins de boîtes, ce qui est le bon résultat.

Ce qu'il fait réellement bien

Explorer l'espace des défaillances. « Quelles sont toutes les façons dont cela peut mal tourner ? » est un problème de rappel couvrant un corpus gigantesque de rapports post-mortem, de comptes rendus d'incidents et de fils de discussion riches en enseignements durement acquis, et c'est exactement à cela que servent ces outils. Il fera ressortir le mode de défaillance que vous auriez découvert en production dans huit mois.

Ce qu'il ne peut pas faire, c'est les classer, car le classement nécessite de connaître votre trafic, votre équipe, votre tolérance et votre budget. La répartition des rôles est donc claire : il génère la liste, vous la hiérarchisez. Quiconque vous dit qu'il peut effectuer ce classement vous vend quelque chose.

Prompt 1 - le terrain n'est pas vierge

Rien d'autre sur cette page ne fonctionne tant que le modèle ne sait pas ce qui existe déjà. Répondez honnêtement, y compris sur les aspects embarrassants.

Ne proposez pas encore d'architecture. Je vais décrire ce qui existe déjà. Lisez-le, puis dites-moi ce que vous devez encore savoir avant de concevoir quoi que ce soit. CE QUI FONCTIONNE AUJOURD'HUI : - Langages, frameworks, bases de données, hébergement, actuellement en en production actuellement - Ce qui est déployé, à quelle fréquence et comment c'est déployé - Quels sont les modes de défaillance actuels. Qu'est-ce qui déclenche réellement nos alertes. CE QUE JE NE PEUX PAS MODIFIER : - Systèmes que je ne possède pas, intégrations que je ne peux pas interrompre, contrats qui dictent le comportement - Contraintes de conformité ou de résidence des données - Tout ce que l'entreprise s'est engagé à fournir à l'extérieur QUI LE CONSTRUIT : - Le nombre d'ingénieurs, leur ancienneté et ce qu'ils ont déjà fait fonctionner en production auparavant - Ce qu'aucun d'entre eux n'a jamais exploité en - S'il y a quelqu'un d'astreinte, et si cette astreinte est rémunérée LES CHIFFRES RÉELS : - Charge actuelle, pas projetée. Utilisateurs, requêtes, volume de données. - La croissance que nous avons réellement enregistrée l'année dernière, et non le plan Ensuite, avant de proposer quoi que ce soit : dites-moi lequel de ces contraintes limite le plus l'espace de conception, et dites clairement lesquelles de mes réponses semble davantage relever de l'aspiration que de la mesure.

Prompt 2 - la liste des renoncements

La partie qu'un modèle ne propose jamais spontanément, et la partie qui constitue réellement la décision.

Pour chaque option que vous proposez, ne commencez pas par ce qu'elle permet. Commencez par ce à quoi elle nous fait renoncer. Pour chaque option : - Que ne pourrons-nous plus faire ensuite, ou seulement à un coût important ? - Qu'est-ce qui devient irréversible, et quel est le coût pour revenir en arrière dans 12 mois ? - Quelle garantie abandonnons-nous - cohérence, ordre, atomicité, possibilité de déployer indépendamment, possibilité de de raisonner sur le système en une seule fois ? - Quelle nouvelle catégorie de bogue cela rend-elle possible, alors qu'il est actuellement impossible ? - Qu'est-ce que cela impose à toute fonctionnalité future, qu'elle que cette fonctionnalité en ait besoin ? Ensuite, en une phrase par option : le problème que nous préférerions que j'ai. Ce n'est qu'après tout cela que vous me direz ce que chaque option permet. Si une l'option n'entraîne pas de renoncements significatifs, dites-le et traitez cela comme suspect plutôt que comme une recommandation.
À la une : Skill
Viktor - Skill AI d’architecte logiciel
Viktor - Skill AI d’architecte logiciel
29 $ · paiement unique

Contient ce qui fait la différence ici : ce que vous exécutez déjà, ce que vous n'êtes pas autorisé à modifier et les décisions que vous avez déjà prises. Ressaisir vos contraintes réelles dans une conversation vide à chaque fois explique pourquoi la plupart des gens abandonnent et acceptent la réponse de type greenfield, et une nouvelle session se fera un plaisir de contredire l'architecture sur laquelle vous vous êtes mis d'accord le mois dernier.

Voir Viktor - Skill d'architecte logiciel AI →

Prompt 3 - interrogez les flèches

Ignorez les boîtes. Pour chaque flèche de cette conception, répondez : 1. Synchrone ou asynchrone ? Si c'est synchrone, quel est le que fait l'appelant pendant l'attente, et que voit l'utilisateur ? 2. Que se passe-t-il lorsqu'elle échoue ? Réessayer, échouer, mettre en file d'attente, dégrader ? 3. S'il réessaie : l'opération est-elle idempotente ? Si elle ne l'est pas, que fait réellement un doublon dans le monde réel - facturer deux fois, envoyer deux fois, compter deux fois ? 4. Quel est le délai d'expiration, et que se passe-t-il après son expiration ? 5. L'ordre est-il important ici ? Si oui, qu'est-ce qui le garantit ? Si rien ne le garantit, dites-le. 6. Si cette flèche est indisponible pendant une heure, qu'est-ce qui fonctionne encore et qu'est-ce qui ne l'est pas ? Qui s'en aperçoit en premier : nous ou le client ? 7. Quel est le contrat de données, et que se passe-t-il lorsqu'un côté la modifie ? Ensuite : quelle flèche est celle qui réveillera quelqu'un, et quelles flèches n'existent que parce que nous avons dessiné des boîtes qui n'étaient pas nécessaires séparer ? Nommez-les. Fusionner deux boîtes est une réponse valable et je veux en entendre parler si cela s'applique. CONCEPTION : [PASTE OR DESCRIBE]

Prompt 4 - concevez-le pour un dixième de l'échelle

L'heure la plus utile que vous passerez. Elle sépare la complexité structurelle de la complexité ambitieuse, et la réponse est souvent inconfortable.

Reprenez la conception dont nous venons de discuter. Concevez maintenant le même système pour un dixième de la charge que je vous ai indiquée, avec la même équipe. Répondez ensuite : - Qu'avez-vous supprimé ? - Parmi les éléments supprimés, lesquels résolvaient un problème que j'ai réellement aujourd'hui, et lesquels résolvaient un problème que je attendez-vous avoir ? - Pour chaque élément de complexité supprimé : à quel moment précis et point mesurable faudrait-il le réintégrer ? Donnez-moi un nombre, pas « quand nous passerons à l'échelle ». - Quel serait le coût d'ajouter cela plus tard, comparé à sa construction maintenant ? Soyez honnête lorsque reporter est réellement pire. Enfin : si je construisais la version plus petite, que regretterais-je dans deux ans, et de quoi serais-je satisfait ? Défendez les deux points de vue correctement plutôt que de me rassurer sur le choix que je semble préférable.

Prompt 5 - l'espace des défaillances, que vous classerez ensuite

Générez toutes les façons dont ce système peut échouer. Soyez exhaustif plutôt que sélectif - je me chargerai de la priorisation, ce n'est pas votre tâche et vous n'avez pas mes chiffres. Couvrir au minimum : - Chaque composant défaillant seul, et l'effet produit - Défaillance partielle : lent plutôt qu'à l'arrêt - Le datastore : indisponible, lent, plein, corrompu, restauré à partir d'une ancienne sauvegarde - Partition réseau entre deux parties quelconques - Une dépendance qui modifie le comportement sans nous en informer - Charge dix fois supérieure aux prévisions, arrivant en une minute - Charge arrivant de manière inégale : un client, une clé, un locataire - Décalage d'horloge, messages en double, messages dans le désordre - Un déploiement effectué à moitié - Des données valides mais absurdes Pour chacune : ce qui casse, ce que voit l'utilisateur, comment nous le découvrons et s'il se rétablit de lui-même. Signalez ensuite les défaillances silencieuses - celles où le système continue de pose normalement, et les réponses sont fausses. Ce sont celles que je veux au premier plan, et ce sont celles qu'une revue de conception oublie.

Invite 6 - comment y parvenir concrètement

Les conceptions ex nihilo ignorent cette étape, et c'est là que se trouve le coût réel. Une architecture cible sans chemin de migration n'est qu'un souhait.

Nous ne construisons pas cela à partir de rien. Voici ce qui existe : [DESCRIBE]. Donnez-moi le chemin d'ici à la conception cible, par étapes qui peuvent-elles être livrées indépendamment, avec le système opérationnel tout au long du processus. Pour chaque étape : - Ce qui est livré, et l'état du système après son - Pouvons-nous nous arrêter ici définitivement tout en étant mieux lotis que en sont-elles maintenant ? Si la réponse est non pour une étape quelconque, cette étape est trop grand - découpez-le. - Ce qui s'exécute en parallèle avec l'ancien chemin, et pendant combien de temps - Comment la restaurer après sa mise en production, et non avant - Quelles données doivent être migrées, et doivent-elles l'être migré deux fois - Ce qui se dégrade pendant cette étape, et qui le ressent Ensuite : le coût total en semaines d'ingénierie, et le point de non- rendement - l'étape après laquelle revenir en arrière devient impraticable. Si la réponse honnête est que la migration coûte plus cher que le que la conception cible en vaut la peine, dites-le clairement.

Deux choses qu'il affirmera alors qu'il ne peut pas les savoir

Chiffres de performance. Si on lui demande combien de requêtes par seconde une conception traitera, ou quelle sera la latence, il produira un chiffre. Il n'en a aucune idée. Ces chiffres dépendent de votre matériel, de la structure de vos données, de vos schémas de requêtes et de la répartition de vos accès, et la seule façon de les obtenir est de mesurer. Considérez tout chiffre de débit, de latence ou de capacité qu'il fournit comme un espace réservé, et prévoyez un test de charge à la place du chiffre.

Versions actuelles, limites et tarifs. Quotas des services, limites des bases de données gérées, tailles d'instances, tarifs facturés par un fournisseur cloud, version ayant rendu obsolète telle autre. Tout cela évolue, et le modèle répond à partir de ce qu'il a vu en dernier. Obtenez chacun de ces éléments dans la documentation actuelle du fournisseur lui-même, le jour où vous prenez votre décision, car une architecture fondée sur un quota obsolète est une conception qui échouera au bout d'un an, au pire moment possible.

Là où cela échoue

Échec Ce qui se passe Que faire à ce sujet
Terrain vierge par défaut Une conception qui part du principe qu'il n'y a rien d'existant, aucun système historique et rien qu'il vous soit interdit de toucher Décrivez ce qui s'exécute aujourd'hui, y compris les aspects embarrassants, avant de demander quoi que ce soit
Conçu pour le pic L'architecture d'une entreprise qui a rencontré le problème intéressant et l'a documenté Demandez le même système avec un dixième de la charge, puis comparez
Des capacités, jamais de renoncements Ce que la conception permet, sans dire ce à quoi vous avez renoncé Exigez d’abord la liste des renoncements, et considérez comme suspecte toute option qui n’en comporte aucune
De beaux diagrammes Des boîtes et des flèches où chaque question difficile se trouve dans une flèche et où aucune n’a de réponse Interrogez chaque flèche. Fusionner deux boîtes est une issue valable
Des performances inventées Un débit de requêtes par seconde ou une valeur de latence sans rien pour l’étayer Traitez chaque chiffre comme un espace réservé pour un test de charge
Des informations obsolètes sur la plateforme Quotas, limites, types d’instances et tarifs tels qu’il les a vus la dernière fois La documentation du fournisseur, telle qu’elle se présente le jour venu, pour chacune d’elles
Aucun chemin de migration Une conception cible qui ne tient pas compte de la manière d’y parvenir alors que le système est en production Exigez des étapes déployables indépendamment, chacune pouvant être interrompue
Il établit un classement lorsqu’on le lui demande Lorsqu’on lui demande quelle défaillance est la plus importante, il répond sans aucun de vos chiffres Laissez-le générer l’espace. Vous vous chargez de l’ordonnancement

Comment installer le Skill Viktor ?

Le téléchargement est un fichier ZIP contenant SKILL.md à la racine de l’archive, et non dans un dossier imbriqué - cette structure de dossiers est la raison habituelle pour laquelle un téléversement échoue. Dans l’application de bureau Claude, ouvrez Personnaliser → Skills, téléversez le ZIP et activez-le.

Les Skills nécessitent l’exécution de code, à activer sous Paramètres → Fonctionnalités. Le centre d’aide d’Anthropic indique actuellement que les Skills sont disponibles avec les forfaits Free, Pro, Max, Team et Enterprise, tandis que son tutoriel Academy liste les forfaits Pro, Max, Team et Enterprise - donc, si vous utilisez le forfait gratuit, vérifiez les options Paramètres → Fonctionnalités de votre propre compte plutôt que de vous fier à l’une ou l’autre page. Le guide complet se trouve dans le guide d’installation du Skill.

Dans ChatGPT ou Gemini, il n’y a pas d’étape de téléversement : ouvrez SKILL.md, copiez le contenu et collez-le dans les instructions personnalisées. Vous perdez le déclenchement automatique, mais vous conservez la méthode.

À qui cela s’adresse-t-il ?

Les architectes et ingénieurs principaux qui veulent un partenaire de réflexion capable de les contredire, les responsables techniques qui prennent des décisions de conception au-delà de leur niveau de rémunération, et les fondateurs qui décident comment construire avant de s’y engager. Cela fonctionne dans Claude, ChatGPT ou n’importe quel chat AI.

Les rôles d’ingénierie sont répartis dans leurs propres Skills, à 29 $ chacun, avec un téléchargement unique :

L’ensemble plus large comprend les Skills pour développeurs logiciels et les Skills pour les logiciels et l’IT.

En résumé :

Une architecture est une liste de choses que vous avez choisi de ne pas pouvoir faire, et un modèle ne fera jamais que décrire des capacités, car le corpus est rédigé par des personnes dont le problème intéressant méritait d’être publié. Dites-lui ce qui fonctionne déjà, ce que vous ne pouvez pas modifier et qui le construit, avant qu’il ne propose quoi que ce soit. Demandez les renoncements avant les possibilités, et considérez une option sans inconvénients comme un avertissement plutôt que comme une recommandation. Ignorez les boîtes et examinez chaque flèche, car c’est là que résident les pannes, l’ordre d’exécution, l’idempotence et le rayon d’impact - et acceptez de regrouper deux boîtes en une seule. Concevez le même système pour un dixième de la charge afin de découvrir quelle complexité est indispensable. Faites-lui générer tout l’espace des pannes et effectuez vous-même le classement. Et faites-lui présenter le chemin de migration, par étapes où vous pourriez vous arrêter, car une conception cible sans chemin pour l’atteindre n’est qu’un souhait. Pour vos contraintes réelles et vos décisions passées conservées entre les sessions, Viktor - Skill AI d’architecte logiciel. Fonctionne avec Claude, ChatGPT et toute conversation avec une AI, avec une garantie de remboursement sous 30 jours.

Skill · .md · Fonctionne avec Claude et ChatGPT

Viktor - Skill AI d’architecte logiciel

Il demande ce qui fonctionne déjà avant de proposer quoi que ce soit, commence par ce qu’une conception empêche plutôt que par ce qu’elle permet, examine les flèches au lieu de dessiner des boîtes et présente le chemin de migration par étapes où vous pourriez vous arrêter. Aucun abonnement. Il vous appartient définitivement.

$19
Obtenir le Skill Viktor →

KissMySkills est une marketplace proposant plus de 1 800 Skills AI, plus de 80 packs de prompts, plus de 75 agents et des outils gratuits pour Claude, ChatGPT et toute conversation avec une AI.

Guides de Skills associés

Passez à la pratique

Ou tous les skills avec Unlimited Voir les offres →

Foire aux questions

Can Claude design a software architecture?+

It can produce a design, and the design will be greenfield and maximal, because the material it learned from was written by people describing systems that worked at a scale worth writing about. Nobody publishes a post about the boring monolith that is still fine. So you get the architecture of a company larger than yours, on an empty field, with the foreclosures left out. That is correctable, but not by asking better questions about the design - only by changing what the model is allowed to assume.

Why does AI always suggest microservices and Kubernetes?+

Because those are the write-ups of organisations that genuinely needed them, and there are no write-ups of the companies that did fine without. The average of the literature is therefore an architecture for a larger company. The cheapest correction is to ask for the same system at one tenth of the load you stated, with the same team, then ask what was removed and at what specific measurable point each removed piece would need to come back.

What is an architecture, really?+

A list of things you have decided you will not be able to do. Choosing eventual consistency forecloses certain guarantees, choosing a monolith forecloses independent deployment, choosing a particular store forecloses certain shapes of growth. The foreclosures are the decision. A model leads with capabilities every time and will not volunteer what you gave up, so ask for the foreclosure list before the enablement list - and treat an option that appears to have no downsides as suspicious rather than as a recommendation.

Why are AI architecture diagrams misleading?+

Because the boxes are the easy part. A service that does one clear thing is a solved problem. All of the difficulty is in the arrows, and an arrow is a claim that two things can talk which the diagram never justifies. Synchronous or asynchronous, what happens on failure, whether a retry is safe, what the timeout is, whether order matters and what guarantees it, what still works if this arrow is down for an hour. Interrogate the arrows and the design usually changes, often collapsing back into fewer boxes.

What is AI genuinely good at in architecture work?+

Generating the failure space. Asking what are all the ways this can go wrong is a recall problem across an enormous body of postmortems and incident write-ups, which is exactly what these tools are for, and it will surface the failure mode you would otherwise have found in production in eight months. What it cannot do is rank them, because ranking needs your traffic, your team, your tolerance and your money. It generates the list, you order it.

Can it estimate how much load my design will handle?+

It will give you a number and it has no idea. Throughput, latency and capacity depend on your hardware, your data shape, your query patterns and your access distribution, and the only way to get them is to measure. Treat any performance figure it offers as a placeholder where a load test should go. The same applies to service quotas, managed-database limits, instance sizes and cloud pricing, all of which change and all of which it answers from whatever it last saw.

Why do AI designs never include a migration path?+

Because greenfield designs do not need one, and greenfield is what the corpus describes. In reality a target architecture with no route to it is a wish, and the migration is where most of the cost lives. Ask for the path in steps that each ship independently with the system live, and apply one test to every step: could we stop here permanently and still be better off than we are now? If the answer is no, the step is too big. Also ask where the point of no return is.

How do I install the Viktor skill?+

The download is a ZIP with SKILL.md at the root of the archive rather than inside a nested folder, which is the usual reason an upload fails. In the Claude desktop app open Customize, then Skills, upload the ZIP and toggle it on. Skills need code execution enabled, under Settings then Capabilities. Anthropic's help centre currently lists Skills on Free, Pro, Max, Team and Enterprise, while its Academy tutorial lists Pro, Max, Team and Enterprise, so if you are on the free plan check Settings then Capabilities for your own account rather than trusting either page. In ChatGPT or Gemini there is no upload step, so open SKILL.md, copy the contents and paste them into custom instructions.

~/get-started

Skills qui fonctionnent. Sans fioritures.

Parcourez chaque skill, prompt pack et agent de la boutique.

Parcourir toutes les compétences →Ou essayez les outils gratuits