Sakana Fugu Ultra : Je L'ai Vu Battre Stockfish

Sakana Fugu Ultra : Je L'ai Vu Battre Stockfish

Le détail qui m'a arrêté n'était pas un benchmark. C'était une partie d'échecs jouée sans échiquier.

Pas d'image des pièces. Pas de grille de coordonnées. Juste un modèle maintenant l'état complet du jeu dans sa tête, coup après coup, contre un moteur Stockfish classé autour de 2 100 ELO — le genre de force qui bat presque n'importe quel joueur de club humain que vous rencontrerez. Et Sakana Fugu Ultra n'a pas juste survécu. Il a gagné quatre parties d'affilée, chacune se terminant par un échec et mat, contre trois modèles de frontière et le moteur.

C'est le moment où j'ai réalisé que je pensais à tout cela de travers. Je suis entré dans la vidéo sur Sakana Fugu Ultra en m'attendant à un autre reel de hype "nouveau modèle bat GPT", le genre que j'ai appris à ignorer au premier coup d'œil. Ce que j'ai obtenu à la place était un argument discrètement radical : peut-être que le prochain saut en capacité IA ne vient pas d'un cerveau plus gros. Peut-être qu'il vient d'un comité plus intelligent.

Je veux être franc sur ce qu'est cet article, car l'honnêteté compte plus que le clic. Je n'ai pas exécuté l'API de Fugu moi-même — l'accès est restreint, et au lancement il est bloqué dans l'UE/EEE pendant que Sakana travaille sur le RGPD. Je ne vais donc pas prétendre que je l'ai déployé sur un projet client mardi dernier. Ce que je peux faire est quelque chose de plus utile : prendre les résultats de tests qui existent, les recouper avec la recherche publiée de Sakana, et vous dire ce qu'ils signifient réellement pour la façon dont vous choisissez vos outils en 2026. Les chiffres ci-dessous proviennent des tests sources et des matériaux propres de Sakana. Le jugement est le mien.

Laissez-moi vous montrer pourquoi "est-ce mieux que GPT-5.5 ?" s'avère être complètement la mauvaise question.

Qu'est-ce que Sakana Fugu Ultra, et pourquoi n'est-ce pas un modèle normal ?

Sakana Fugu Ultra n'est pas un modèle fondamental — c'est un système d'orchestration multi-agents qui décompose une tâche, route les sous-tâches vers différents LLMs spécialisés, puis critique, vérifie et synthétise leurs sorties en une seule réponse. Quand vous l'appelez via son unique point d'accès API, vous ne parlez pas à un ensemble de poids comme vous le faites avec Opus 4.8 ou GPT-5.5. Vous parlez à un chef d'orchestre qui sait quels musiciens appeler pour quel passage.

Sakana AI est un laboratoire de recherche à Tokyo, et Fugu a été lancé le 22 juin 2026. L'étiquette "modèle" le sous-estime. Voici l'architecture en termes simples : Fugu prend votre prompt, le décompose en morceaux et attribue des rôles à travers un pool interchangeable de modèles de frontière — pensez Penseur, Travailleur, Vérificateur. Un modèle conçoit un plan. Un autre exécute une partie. Un troisième vérifie le travail. Fugu assemble les résultats et vous remet la sortie finie.

Le mot "interchangeable" fait un travail considérable ici. Parce que Fugu route vers des modèles au lieu d'en être un, le pool peut grandir à mesure que de nouveaux modèles de frontière apparaissent — sans réentraînement. C'est un pari véritablement différent sur l'origine de la valeur de l'IA. La plupart des labos font la course pour construire le cerveau unique le plus intelligent. Sakana parie que coordonner les cerveaux que nous avons déjà est le chemin moins cher et plus rapide vers plus de victoires.

Voici la partie que la plupart des couvertures comprennent mal, et elle change tout : l'orchestration de Fugu est apprise, pas codée en dur. Ce n'est pas un routeur construit à partir de logique if/else et d'un comparateur de mots-clés. Selon la recherche de Sakana, Fugu est lui-même un modèle de langage entraîné dont le travail est d'appeler d'autres LLMs — et il a appris comment les coordonner à partir de deux articles d'ICLR 2026 : Trinity (un coordinateur évolué qui attribue les rôles de Penseur/Travailleur/Vérificateur) et The Conductor (entraîné par apprentissage par renforcement pour découvrir des stratégies de coordination en langage naturel). Le système a appris quoi dire à chaque modèle pour qu'un pool diversifié surpasse n'importe quel travailleur individuel.

Et il y a un détail surprenant enfoui dedans. Fugu peut s'appeler lui-même récursivement — lire sa propre sortie précédente, décider si sa première tentative de coordination était insuffisante, et lancer un workflow correctif. La profondeur de cette récursion devient un axe de calcul réglable au moment de l'inférence. Vous pouvez investir plus de réflexion en allant plus profond, sans rien réentraîner. C'est un nouveau type de mise à l'échelle au moment du test, et c'est le genre d'idée qui est évidente en rétrospective et que presque personne n'a livré en premier.

Donc quand vous voyez Fugu "battre" un modèle de frontière sur un benchmark, tenez ce résultat à la lumière. Bien sûr qu'un système qui décompose, délègue et vérifie réussit bien sur les tâches qui récompensent la résolution soigneuse de problèmes. C'est littéralement ce pour quoi il est construit. La question intéressante n'est pas s'il gagne — c'est où il gagne, et combien ça vous coûte pour y arriver.

Cette question du coût est là où l'histoire devient inconfortable.

Le test du trader desk : où va vraiment l'argent

Je veux commencer par le test le moins dramatique, parce que c'est le plus honnête. Le brief : construire un "trader desk en direct" — un front-end plus back-end, le type d'application multi-composants que de vraies personnes construisent réellement. Quatre systèmes ont reçu le même prompt. Voici ce qu'ils ont utilisé, tel que rapporté dans la source :

Lisez ce tableau lentement, car il contient deux histoires.

La première histoire est celle que Sakana veut que vous voyiez : Fugu a produit l'UI la plus belle et la plus complète. Si "rendez-le impressionnant du premier coup" est le travail, Fugu a livré. L'orchestration a payé en finition — plusieurs modèles se vérifiant mutuellement tendent à attraper les lacunes qu'un seul passage laisse derrière.

La seconde histoire est celle qui compte pour votre budget. Fugu a coûté 0,51 $ — environ 17 fois ce que Chinchilla 5.2 a facturé pour une version fonctionnelle de la même chose. Il a aussi brûlé le plus de tokens. Ce n'est pas un bug. C'est l'architecture. Chaque fois que Fugu décompose une tâche, la route et vérifie le résultat, il fait plus d'appels de modèle qu'un modèle unique ne le ferait. La coordination a un surcoût, et vous payez pour cela en tokens, euros et latence.

Voici où j'atterris, et ce n'est pas là où le marketing me veut : pour une construction simple, cette prime est difficile à justifier. Chinchilla 5.2 vous a donné un trader desk fonctionnel pour trois centimes. Si vous le voulez joli, Opus 4.8 a divisé la différence à 0,31 $ avec un résultat propre. Les 64 centimes supplémentaires de Fugu par rapport à Chinchilla vous achètent de la finition — et sur beaucoup d'outils internes, personne ne note la finition.

Mais "beaucoup d'outils internes" n'est pas chaque travail. Le test du trader desk récompense l'efficacité, donc les outils efficaces ont l'air malins. Changez la tâche pour une qui récompense la coordination, et l'image bascule radicalement.

Le test Crossy Road : quand plus rapide et moins cher produit du moins bon

C'est le test qui a recadré tout le sujet pour moi, et il n'a rien à voir avec quel système est "plus intelligent".

La tâche : construire un jeu 3D style Crossy Road. Même brief, face à face — Fugu Ultra contre Opus 4.8. Voici les chiffres rapportés, et je les présente exactement comme la source les a rapportés, pas comme des chiffres que j'ai moi-même vérifiés :

Fugu était environ 3,5 fois plus rapide, a utilisé environ 10 fois moins de tokens et a coûté environ 5 fois moins. Arrêtez-vous et assimilez cela, car cela contredit le résultat du trader desk que vous venez de lire. Ici, le système orchestré était le frugal.

Et pourtant il a produit le jeu le moins bon. Le clone de Crossy Road de Fugu avait des contrôles de direction inversés — appuyez à droite, allez à gauche. La caméra combattait le joueur. Il n'y avait pas de son. Le jeu était incomplet. Opus 4.8 a dépensé cinq fois plus d'argent et presque quatre fois le temps réel, et a rendu quelque chose de plus soigné et plus fonctionnel — bien que toujours légèrement bogué.

Alors qui a gagné ? C'est la mauvaise question, et c'est exactement le point. Si vous prototypez cinquante concepts de jeux pour trouver celui qui vaut la peine d'être construit, le profil de Fugu est évidemment correct — vous voulez de la vitesse et du bon marché, et vous réparerez la caméra sur la seule idée qui survit. Si vous livrez le jeu pour lequel les joueurs vont réellement payer, la finition d'Opus 4.8 vaut chaque dollar supplémentaire.

Remarquez ce qui vient de se passer sur deux tests. Sur le trader desk, Fugu était l'option chère. Sur Crossy Road, Fugu était l'option bon marché. Le même système. La variable n'était pas Fugu — c'était la tâche. Le surcoût d'orchestration est un impôt fixe qui rapporte énormément sur certains travaux et vous saigne sur d'autres, et vous ne pouvez pas savoir lequel sans faire correspondre la tâche à l'architecture.

C'est la compétence que personne n'enseigne encore : lire une tâche et prédire quelle forme de système lui convient. Laissez-moi vous donner la règle générale que j'utiliserais.

Devriez-vous utiliser Fugu Ultra ou simplement choisir un modèle de frontière ?

Utilisez Fugu Ultra quand la tâche est multi-composants, à haut niveau de détail, et bénéficie de la vérification — constructions d'UI, simulations, tout ce où la vérification croisée attrape les erreurs qu'un seul passage rate. Tournez-vous vers un modèle de frontière unique comme Opus 4.8 ou GPT-5.5 quand vous avez besoin de vitesse prévisible, de faible coût et d'une boucle de feedback serrée. Le facteur décisif n'est pas la capacité. C'est si la décomposition-et-vérification récupère son surcoût sur ce travail spécifique.

Voici la décision que j'exécuterais réellement, dans l'ordre :

1. Est-ce un artefact impressionnant unique ou une boucle d'itération serrée ? La finition unique favorise la boucle de vérification-et-synthèse de Fugu. L'itération rapide favorise un modèle unique — vous ne voulez pas de latence d'orchestration entre chaque frappe de feedback.
2. À quel point la tâche est-elle à long terme ? Celle-ci est importante. Les résultats rapportés montrent que Fugu est parfois à la traîne sur le travail large et à long terme — des choses comme Sweep Bench Pro — précisément parce que le surcoût d'orchestration et les points de défaillance de coordination se composent sur de nombreuses étapes. Plus de pièces mobiles signifie plus d'endroits pour casser.
3. Quel est votre plafond de coût et votre plancher de qualité ? Si vous avez un budget serré et une barre de qualité indulgente, un modèle efficace unique gagne presque toujours. Si la finition n'est pas négociable et le budget est flexible, les appels supplémentaires de Fugu méritent leur coût.
4. Doit-il fonctionner dans l'UE ? Au lancement, Fugu n'est pas disponible dans l'UE/EEE pendant que Sakana travaille sur le RGPD. Si votre stack ou vos utilisateurs y vivent, la décision est prise pour vous.

Sur les benchmarks purs, la source rapporte que Fugu obtient de bons scores en ingénierie, raisonnement scientifique, codage et tâches agentiques — et surpasse souvent Mythos 5 sur des benchmarks spécifiques comme Live Code Bench et BBQ Evil, exactement le type qui récompense la décomposition soigneuse et la vérification. Mais il reste en deçà des vrais modèles de frontière comme Fable 5 sur les tâches réelles plus désordonnées. Les victoires sur les benchmarks sont réelles et elles sont en partie un artefact de ce pour quoi l'orchestration est construite. Les deux choses sont vraies.

Encore une mise en garde honnête que je ne vais pas enterrer : la plupart des revendications de benchmark des gros titres sont les propres chiffres de Sakana. Les benchmarks auto-rapportés de l'entreprise qui vend le produit sont du marketing jusqu'à ce que des évaluateurs indépendants les reproduisent. Je ne dis pas qu'ils sont faux — je dis que la charge de la preuve incombe à Sakana, et pour le moment elle n'est que partiellement satisfaite. Les résultats de tests tiers ci-dessus (trader desk, Crossy Road) sont plus fiables précisément parce qu'ils n'ont pas été réalisés par Sakana.

Si toute la direction multi-modèles et ensembles vous intéresse, j'ai retracé la version précoce de ce modèle dans mon analyse des ensembles d'IA open source, et j'ai couvert le lancement de Fugu en contexte aux côtés des autres sorties de juin dans mon tour d'horizon des modèles IA de juin 2026. Cet article est la plongée profonde sur Fugu seul ; ce tour d'horizon est la carte plus large.

Maintenant — les tests où Fugu m'a véritablement impressionné, et où l'architecture d'orchestration cesse d'être un compromis et commence à être un avantage.

Où l'orchestration brille vraiment : simulations, terrain et un échiquier qu'il ne peut pas voir

Trois résultats m'ont fait passer de sceptique à "ok, c'est réel."

La simulation du trou noir. Le brief était une simulation surréaliste de trou noir — nom de code "Singularity". Fugu a produit une visualisation détaillée et bien rendue qui a surpassé GLM MiniMax et Chinchilla 2.7 Code en précision visuelle. C'est exactement le type de tâche où l'orchestration devrait gagner : rendre correctement une scène aux nuances physiques implique plusieurs sous-problèmes — la géométrie, l'éclairage, la physique de distorsion, le style surréaliste — et un système qui peut router chacun vers un modèle capable et vérifier le composite a un avantage structurel sur un modèle unique essayant de tout maintenir en même temps.

Le simulateur de vol. Même histoire, domaine différent. Fugu a généré un simulateur de vol à terrain infini semi-précis qui a surpassé GLM 5.2 et MiniMax, qui ont tous deux livré des résultats limités. "Terrain infini" est un problème de décomposition déguisé — génération de terrain, la physique de vol, la caméra, la boucle de rendu — et la décomposition est le terrain de Fugu.

Et ensuite les échecs. J'y reviens sans cesse parce que c'est la démonstration la plus propre de ce que "maintenir l'état à travers la coordination" vous apporte réellement. Échecs à l'aveugle, en une seule fois, pas d'échiquier visuel — le système doit suivre l'ensemble de la position en mémoire de travail tout au long de la partie. Fugu a gagné quatre parties consécutives contre trois modèles de frontière et un moteur Stockfish autour de 2 100 ELO, terminant chaque partie par un échec et mat. Il a maintenu l'état du jeu et la précision des coups mieux que des adversaires qui, sur le papier, sont plus capables.

Pourquoi cela arrive-t-il ? Parce qu'un vérificateur dans la boucle attrape l'erreur avant qu'elle ne soit commise. Un modèle unique jouant aux échecs à l'aveugle a un seul essai pour suivre correctement l'échiquier à chaque coup. Un système orchestré peut faire proposer un coup par un composant et en faire vérifier la position résultante par un autre contre l'historique des coups. Ce n'est pas de la magie — c'est la même boucle de décomposer-et-vérifier, appliquée à un problème où un seul faux pas perd la partie. Toute la raison d'être de l'architecture est d'attraper l'erreur que le soliste commettrait.

Si vous avez lu jusqu'ici, voici le changement que je veux que vous emportiez : pendant des années nous avons demandé "quel modèle est le plus intelligent ?" La question plus utile de 2026 est "quelle forme de système convient à ce travail ?" Et "un orchestrateur qui route entre de nombreux modèles" est maintenant une réponse réelle et en production à cette question — pas une curiosité de recherche.

Ce que j'avais tort concernant l'origine du prochain saut

L'heure de la franchise, parce qu'une revue d'outil qui ne liste que des fonctionnalités est une fiche technique, et ça vous pouvez l'obtenir n'importe où.

Premièrement, j'avais tort sur la forme du progrès. J'ai supposé que le prochain saut de capacité viendrait d'un modèle unique plus grand — plus de paramètres, plus d'entraînement, un cerveau plus gros. Les résultats de Fugu suggèrent qu'une part significative du progrès à court terme viendra de la coordination à la place : tirer plus des modèles que nous avons déjà en routant intelligemment entre eux et en vérifiant la sortie. C'est une forme de progrès plus humble, moins glamour. Elle ne fait pas un gros titre accrocheur "nouveau modèle". Je pense qu'elle a été sous-estimée exactement pour cette raison.

Deuxièmement, l'axe du coût est maintenant aussi important que l'axe de la capacité, et la plupart des couvertures l'ignorent encore. Tout le monde fait des benchmarks d'intelligence. Presque personne ne fait des benchmarks d'euros-par-tâche-accomplie. Les tableaux du trader desk et de Crossy Road sont l'illustration la plus claire que j'ai vue que "meilleur" est maintenant un mot dépendant du budget. Quand je conseille des équipes, la première question n'est plus "quel modèle est le plus intelligent" — c'est "quelle est votre tolérance pour le coût versus la finition sur ce travail." La plupart des jours, je prends le résultat moins cher et je répare la caméra moi-même.

Troisièmement — et c'est la limitation avec laquelle Sakana ne mènera pas — le surcoût d'orchestration est un impôt réel et récurrent. Plus d'appels de modèle signifient plus de latence, plus de coût et plus de points de défaillance. Chaque saut entre modèles est un endroit où le workflow peut perdre du contexte ou mal router. Sur les tâches à long terme, ces points de défaillance se composent, ce qui est exactement pourquoi Fugu est à la traîne sur les benchmarks les plus larges. Un orchestrateur n'est fiable que par son transfert le plus faible, et il a plus de transferts qu'un modèle unique. Ce n'est pas un défaut à corriger — c'est le coût inhérent du design.

Si le modèle d'orchestration vous a rendu curieux d'en faire tourner un vous-même, j'en ai testé quelques-uns — voir mon expérience pratique avec l'orchestrateur d'agents OpenAI Symphony, qui aborde le même problème de coordonner-beaucoup-de-modèles depuis l'angle du harness de code. Et si vous envisagez d'intégrer une couche d'orchestration multi-agents dans votre propre stack — déterminer où elle gagne son surcoût versus où un modèle unique est le choix le plus sensé — c'est exactement le type de décision d'architecture que je prends en charge via mon Fiverr. La réponse honnête est généralement "utilisez l'orchestration pour les 20 % des tâches qui en ont véritablement besoin, et un modèle unique rapide pour le reste", et bien calibrer cette répartition est l'essentiel de la valeur.

Alors, où Fugu s'inscrit-il vraiment ? Laissez-moi rendre cela concret.

À quoi s'attendre si vous adoptez Fugu Ultra aujourd'hui

Je ne vais pas inventer une précision que je n'ai pas. Mais les tests rapportés, lus à la lumière de l'architecture, pointent vers une forme cohérente autour de laquelle vous pouvez planifier.

Attendez-vous à ce que Fugu gagne sur les artefacts multi-composants, à haut niveau de détail et uniques — la construction d'UI soignée, la simulation rendue, la génération en plusieurs parties où la vérification attrape ce qu'un seul passage rate. L'UI du trader desk, la simulation du trou noir, le simulateur de vol, les échecs à l'aveugle — tous partagent cet ADN : plusieurs sous-problèmes qui bénéficient d'être divisés, résolus et vérifiés.

Attendez-vous à ce que Fugu soit à la traîne sur le travail à long terme, ouvert ou sensible au coût — les tâches agentiques larges où le surcoût s'accumule, et tout travail où un modèle unique moins cher vous amène à 90 % du chemin pour une fraction de la dépense. Le trader desk à trois centimes de Chinchilla 5.2 est l'histoire d'avertissement : si vous n'avez pas besoin de la finition, vous payez une prime considérable pour elle.

Attendez-vous à payer plus et attendre plus longtemps qu'avec GPT-5.5 ou Opus 4.8 sur des tâches équivalentes, en règle générale. C'est le coût structurel de la coordination, et il ne disparaîtra pas complètement — bien que l'idée de profondeur récursive de Sakana suggère qu'ils ont au moins un bouton pour échanger consciemment du calcul contre de la qualité plutôt qu'à l'aveugle.

Et attendez-vous à ce que cela s'améliore. Fugu a été lancé le 22 juin 2026 ; c'est tôt. Le pool est interchangeable, donc il hérite de chaque nouveau modèle de frontière gratuitement. La coordination est apprise, donc un entraînement continu peut l'affûter. La preuve de concept est déjà convaincante. La question est de savoir si Sakana peut combler l'écart de surcoût assez vite pour faire de l'orchestration le choix par défaut plutôt que le choix spécialiste.

Pour l'instant, ma recommandation est sans glamour et, je pense, correcte : Fugu Ultra est un outil spécialisé, pas un véhicule du quotidien. Pour le travail d'application général, GPT-5.5 et Opus 4.8 vous offrent actuellement un meilleur équilibre coût-vitesse-qualité. Gardez Fugu dans votre kit pour les travaux spécifiques à haut niveau de détail et multi-composants où décomposer-et-vérifier gagne son coût — et surveillez la tendance du surcoût, parce que si elle baisse, tout le calcul change.

Revenez une dernière fois à cette partie d'échecs à l'aveugle. Un système qui ne pouvait pas voir l'échiquier a quand même gagné — non pas parce qu'il était le joueur le plus intelligent à la table, mais parce qu'il avait un coéquipier qui vérifiait son travail avant chaque coup. C'est la vraie leçon de Fugu Ultra, et elle est plus grande qu'un seul produit. La prochaine ère de l'IA ne sera peut-être pas gagnée par le modèle le plus intelligent. Elle sera peut-être gagnée par l'équipe la mieux coordonnée de modèles ordinaires.

Alors la question que je vous laisserais n'est pas "Fugu est-il meilleur que GPT-5.5 ?" C'est celle-ci : parmi les travaux sur votre bureau cette semaine, lesquels résolvez-vous avec un soliste alors qu'ils auraient en fait besoin d'un comité ?

Questions Fréquemment Posées

Sakana Fugu Ultra est-il un modèle fondamental ou un orchestrateur ?

Fugu Ultra est un orchestrateur, pas un modèle fondamental. Il décompose une tâche, route les sous-tâches vers un pool interchangeable de LLMs de frontière, puis vérifie et synthétise leurs sorties via une seule API. Contrairement à Opus 4.8 ou GPT-5.5, il ne génère pas de réponses à partir de ses propres poids — il coordonne d'autres modèles. Voir l'analyse de l'architecture ci-dessus pour le tableau complet.

Fugu Ultra est-il moins cher qu'Opus 4.8 ou GPT-5.5 ?

Cela dépend entièrement de la tâche. Sur une construction Crossy Road, Fugu a coûté selon les rapports environ 5 fois moins qu'Opus 4.8 ; sur une construction trader desk, il était le plus cher des quatre systèmes à 0,51 $. Le surcoût d'orchestration est un impôt fixe qui rapporte sur certains travaux et vous saigne sur d'autres. Le cadre de décision ci-dessus explique comment prédire lequel.

Sur quels benchmarks Fugu Ultra réussit-il bien ?

Fugu obtient selon les rapports de bons scores en ingénierie, raisonnement scientifique, codage et benchmarks agentiques, et surpasse souvent Mythos 5 sur des tâches comme Live Code Bench et BBQ Evil qui récompensent la décomposition et la vérification. Il est à la traîne sur les benchmarks à long terme comme Sweep Bench Pro, où le surcoût d'orchestration s'accumule.

Où Sakana Fugu Ultra est-il disponible ?

Fugu Ultra est accessible via un fournisseur d'API et a été lancé le 22 juin 2026. Au lancement, il n'est pas disponible dans l'UE/EEE pendant que Sakana AI travaille sur la conformité RGPD. Si vos utilisateurs ou votre stack vivent en Europe, cette restriction peut trancher la question pour vous.

Fugu Ultra a-t-il vraiment battu Stockfish aux échecs à l'aveugle ?

Selon les tests sources, oui — Fugu a gagné quatre parties consécutives à l'aveugle (pas d'échiquier visuel) contre trois modèles de frontière et un moteur Stockfish classé autour de 2 100 ELO, terminant chaque partie par un échec et mat. La raison probable est sa conception de vérification-dans-la-boucle, qui attrape l'erreur de suivi de position qu'un modèle unique commettrait.

Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technique ? Je serais ravi de vous aider.

• Fiverr (constructions personnalisées et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io