Cet article utilise Shadowverse: Worlds Beyond pour montrer comment combiner agents IA, simulation, optimisation robuste et mémoire externe afin d’éviter qu’une seule personne doive tout mémoriser et tout tester.
1. « Il faut tout connaître avant de pouvoir diriger » n’est plus qu’à moitié vrai
Avant : chercher, implémenter et tester soi-même. Avec l’IA, l’humain définit le but, l’état final, les contraintes et les critères de succès. Puis il délègue : Cherche. Propose des options. Compare. Implémente. Teste. Rapporte les résultats.
L’humain tranche : « A dehors. B. Ici c’est faux. Reteste. »
C’est déjà du management. Si la même personne décide aussi où investir temps et calcul, si un projet mérite d’exister et comment définir le succès, on se rapproche de la direction.
En 2026, OpenAI présente Codex autour de la délégation à plusieurs agents, du travail parallèle, de la revue humaine et du changement de direction. Son guide AI-native distingue également Delegate, Review et Own.
On passe de humain → travail à humain → employés IA → travail.
Pas de fiches de paie.
Mais une organisation.
2. Le travail du PDG devient moins « connaître toutes les réponses » que « savoir les juger »
Zéro expertise reste dangereux. Quand l’IA annonce « optimisation terminée », il faut demander pourquoi, quelles alternatives, ce qui se passe si les hypothèses bougent, si le test ressemble au réel, si les données sont fraîches et combien coûte une erreur.
Sinon :
IA : « Fini ! »
Humain : « Parfait ! »
Réalité : « Cassé. »
La transition n’est pas de l’expertise vers l’ignorance. Elle va de tout savoir implémenter soi-même à savoir évaluer, contester et gouverner les résultats.
Pas besoin de mémoriser chaque carte. Il faut savoir repérer une moyenne splendide cachant un matchup à 25 %.
3. Avant de jouer à Shadowverse, construisons l’usine de simulation
Boucle normale : commencer, lire, construire, perdre, corriger, perdre, jouer 100 parties, comprendre un peu le meta.
Avec le calcul :
- Collecter toutes les cartes.
- Collecter les decks publics et de tournoi.
- Implémenter règles et effets.
- Définir mulligan et politiques de jeu.
- Simuler des dizaines ou centaines de milliers de parties.
- Créer une matrice de matchups.
- Mesurer faiblesses, variance et bricks.
- Faire tester seulement les finalistes par l’humain.
100 decks × 50 parties = 5 000 tests humains. La machine élimine 95 %.
Le guide est en rédaction avant l’installation du jeu.
Petit souci : la simulation peut durer jusqu’à la sortie du pack suivant.
Nous avons accidentellement créé la R&D.
4. Optimiser juste avant un nouveau pack peut produire « l’optimum qui meurt cinq jours plus tard »
Au 22 août 2026, le neuvième set Revenants of Azvaldt / アズヴォルト・レヴナント était annoncé pour le 27 août.
22 août : « Deck optimal terminé ! »
27 août : « Nouvelles cartes. »
Deck optimal : « Adieu. »
Avant une extension, mieux vaut terminer l’usine : pipeline de données, moteur de règles, matchs IA, agrégation, matrice, robustesse et rapports.
Tout cela se réutilise.
On voulait jouer aux cartes. On fait de l’industrie.
5. Optimisation robuste : pas seulement « meilleure moyenne », mais « survit si le meta bouge »
| Deck | vs Dragon | vs Rune | vs Sword | vs Forest |
|---|---|---|---|---|
| A | 70% | 65% | 60% | 25% |
| B | 57% | 56% | 55% | 54% |
Forest rare ? A semble divin. Forest devient populaire ? A meurt.
B est moins spectaculaire mais survit à une mauvaise prévision.
L’optimisation robuste place les paramètres incertains dans un ensemble de valeurs possibles et cherche une décision acceptable même sous des réalisations défavorables.
On peut perturber le meta, les matchups, premier/deuxième, mulligan, non-pioche d’une pièce clé, erreur de politique.
Pic 95/plancher 20 peut être moins bon que pic 80/plancher 65.
On ne cherche pas le gorille qui frappe le plus fort, mais celui qui fonctionne même dans le mauvais zoo.
6. Mauvaise nouvelle : un simulateur parfait n’empêche pas l’humain de cliquer de travers
L’IA trouve le deck parfait. En vraie partie : « Quelle carte d’abord déjà ? » Défaite.
Mais l’entraînement peut lui aussi être compressé. Extraire mulligans par matchup, positions fréquentes, létaux typiques, erreurs catastrophiques, réponses adverses et décisions à fort impact.
L’humain n’entraîne pas « tout le jeu », mais les 20 % de situations qui déterminent la majorité des résultats.
Recherche : machine. Mining des positions : machine. Décision finale : humain.
Le PDG va aussi sur le terrain, sans 100 heures d’onboarding.
7. Stocker toutes les cartes dans le cerveau n’est-il pas une architecture de stockage absurde ?
Les sciences cognitives parlent de cognitive offloading lorsqu’on utilise notes, appareils ou rappels comme mémoire externe.
Un modèle de 2024 explique le choix par les coûts : mémoire interne limitée donc coût d’opportunité ; mémoire externe nécessitant une action de consultation mais offrant beaucoup plus de capacité.
Dans le cerveau : seulement le cache — principaux archétypes, condition de victoire, menaces fréquentes, zones de lethal, mulligan et branches fréquentes.
Tech à 3 % ?
Lis-la depuis le disque.
8. Les données de cartes WB peuvent réellement être collectées automatiquement
mariokart761/ShadowverseWB_card_data utilise un crawler pour récupérer des données en cinq langues et stocker détails, textes de compétence, évolutions, cartes liées, sets, etc. en JSON.
Personne n’est obligé de saisir « Coût 3… attaque 2… vie 3… » des centaines de fois.
Le directeur crawler est au travail.
ParticleG/shadowverse-wb-db conserve aussi nom, texte, coût, attaque, vie, rareté, set et images dans cards.json.
Mais récupérer le texte ≠ exécuter correctement les règles. « Fanfare : 4 dégâts » est facile à lire; cible, timing, buffs, réduction, board plein : voilà l’enfer.
Catalogue automatisé.
Moteur de règles en heures supplémentaires.
9. Le cerveau humain doit être un moteur de décision, pas une base de données
GitHub / DB → mémoire longue
Crawler → acquisition
Simulateur → expérience virtuelle
Codex / IA → recherche, implémentation, tests, rapports
Humain → objectif, critères, priorité, décision finale
Avant : tout mémoriser et jouer des centaines de parties. Maintenant : faire jouer des centaines de milliers aux machines et recevoir une synthèse.
Ne transforme pas le bureau du PDG en entrepôt de cartes.
Demande au service d’apporter le dossier.
10. Ce n’est plus seulement une stratégie de jeu ; c’est un OS de société unipersonnelle
But, état souhaité, contraintes, recherche IA, comparaison, simulation, robustesse, exécution, revue, correction, mémoire externe.
Même structure pour logiciel, investissement, processus, contenu, recherche, achat et jeu.
On ne construit pas seulement « le meilleur deck », mais une usine de décision.
Les employés sont des IA. L’humain ne mémorise pas chaque détail mais conserve le but, les critères, la confiance et le GO/NO-GO.
On voulait jouer aux cartes.
On devient PDG avant de les connaître.
11. Conclusion : conçois avant de mémoriser ; délègue les expériences avant de grinder
recherche → données structurées → simulation → robustesse → shortlist → test humain
Mémoire :
tout mémoriser → non
tout rendre récupérable → oui
mettre en cache seulement le fréquent et décisif → idéal
Final :
L’IA joue un million de parties.
GitHub se souvient de tout.
L’humain décide l’essentiel.
On voulait juste faire Storm face. On finit par faire du design organisationnel.
Avant le BOUM du Storm,
BOUM du comité exécutif.
