En mars 2026, nous avons repensé l’expérience de moonshot.ai sur l’ensemble de la plateforme. La mise à jour semblait simple : une nouvelle palette de couleurs, une typographie plus resserrée et des animations revues. En pratique, elle a touché les composants partagés, les design tokens, les routes et les couches interactives de tout le site.
Nous avons utilisé Kimi Code CLI, propulsé par Kimi K2.5, comme agent de codage IA pour nous aider à mener cette refonte. Ce projet est devenu un test concret de l’intégration d’un agent en terminal dans un véritable flux de production — et non dans un environnement de démonstration. Cet article revient sur notre manière de l’utiliser et sur les enseignements que nous en avons tirés.
Le véritable enjeu de cette refonte
La refonte de moonshot.ai ne consistait pas à repenser la marque de zéro. L’essentiel du travail de design existait déjà dans Figma. Le vrai défi était d’appliquer ces mises à jour de manière cohérente dans une base de code existante.
Cela impliquait de retracer les tokens partagés, de mettre à jour les composants, de vérifier les comportements interactifs et de s’assurer que l’analytics comme l’accessibilité n’étaient pas affectés. Pris isolément, beaucoup de changements étaient modestes, mais ils traversaient plusieurs couches du site.
Ce type de travail n’est pas difficile à cause d’une complexité algorithmique. Il l’est par son ampleur et l’exigence de cohérence. Le défi consiste à savoir tout ce qu’un changement affecte, puis à s’assurer que rien n’est oublié. Pour y parvenir, nous avons utilisé une connexion Model Context Protocol (MCP) avec Figma afin de mieux aligner les spécifications de design et l’implémentation, d’aider l’agent à comprendre la structure et de réduire l’interprétation manuelle.
Règles de base : rendre l’agent utile
La première étape n’a pas été d’écrire des prompts, mais de poser le contexte. Nous avons utilisé la commande /init pour générer un fichier AGENTS.md, puis consacré environ une heure à l’affiner. Nous y avons documenté le périmètre de la refonte, ce qui ne devait pas changer, la structure du projet et le fonctionnement du processus de build. Nous avons aussi ajouté un fichier de règles couvrant les conventions de nommage, les espacements et les exigences de contraste.
Cette préparation a réduit le besoin de répéter les explications par la suite et rendu le flux de travail avec Kimi Code CLI plus cohérent. Sans contexte propre au projet, l’agent de codage IA tend à produire des résultats raisonnables mais génériques. Avec ce contexte, son comportement se rapproche de celui d’un coéquipier qui connaît déjà la base de code.
Comment nous l’avons réellement utilisé
Cette section détaille l’usage concret de Kimi Code CLI pendant la refonte : cartographie des dépendances, alignement avec le design, exploration des comportements, contrôles de performance et revue des risques d’intégration. L’objectif n’était pas l’automatisation, mais la réduction de l’incertitude dans un refactoring de grande ampleur.
Comprendre ce que le changement affecte
Avant de modifier quoi que ce soit, nous avons demandé à l’agent dans Kimi Code CLI de lire la zone ciblée et de lister ce qui en dépendait. Un seul changement — comme la couleur d’un bouton — peut toucher les sections hero, les zones de téléchargement, les états hover et les tokens partagés, tandis que les composants communs, les timings d’animation et les hooks d’analytics peuvent encore étendre l’impact. Obtenir d’abord une liste des dépendances a limité les surprises et rendu les modifications plus prévisibles.
Faire correspondre le code aux spécifications de design
Nous avons ensuite comparé les composants aux spécifications de design, section par section : hero, navigation, sections produit, CTA de téléchargement et footer. L’agent a produit des listes de changements au niveau des propriétés en comparant les styles aux design tokens et aux valeurs de mise en page. Le processus ressemblait davantage à une automatisation structurée de design system qu’à une vérification visuelle manuelle. La plupart des écarts étaient mineurs — espacement, rayon de bordure ou graisse de police — mais des incohérences plus importantes sont parfois apparues lorsque des composants censés partager des variantes s’étaient éloignés au fil du temps. Le résultat était une liste concrète de modifications, plutôt qu’un exercice de déduction visuelle.
Explorer les nouveaux comportements
La refonte a introduit de nouveaux comportements d’interface qui n’existaient pas encore dans la base de code : un curseur personnalisé, un hero piloté à l’exécution, des cartes d’illustration qui se lancent au survol et des apparitions déclenchées au défilement.
Pour chaque fonctionnalité, nous avons utilisé Kimi Code CLI comme environnement contextualisé en chargeant ensemble la documentation et l’état du dépôt. C’est là que Kimi K2.5 a fait la différence : un contexte plus long facilitait le raisonnement simultané sur l’implémentation et les références.
Les questions étaient pratiques :
Les animations au survol doivent-elles aller jusqu’au bout ou s’interrompre à la sortie ?
L’état du curseur doit-il interagir avec le canvas du hero ?
Que se casse-t-il lorsque plusieurs couches se superposent ?
La grande fenêtre de contexte a permis un flux de travail kimi code plus continu, où l’intention de design et le code cohabitent dans la même session.
Contrôler le poids et les performances
La refonte a introduit une nouvelle police, davantage d’animations et des assets supplémentaires, ce qui a augmenté le poids des pages. Nous avons utilisé l’agent pour adapter le script existant de subsetting de polices et vérifier la sortie ; il nous a ensuite aidés à interpréter les rapports Lighthouse afin d’identifier tôt les régressions. L’objectif n’était pas de tout optimiser à la fin, mais de décider quoi garder ou supprimer tant que les changements restaient limités.
Identifier les risques d’intégration avant le merge
Plusieurs couches interactives — animation d’entrée, curseur, canvas du hero — partagent des comportements d’ordre d’affichage et de pointeur tout en vivant dans des composants distincts ; un changement dans une couche peut donc en affecter d’autres. Nous devions aussi tenir compte des différences entre navigateurs et systèmes d’exploitation, où le CSS et le rendu ne se comportent pas toujours de la même façon. Avant de merger des lots de changements, nous avons transmis les diffs à Kimi Code CLI et lui avons demandé de retracer les interactions susceptibles d’être affectées, puis nous avons vérifié ces parcours dans le navigateur et effectué une passe légère sur plusieurs environnements.
Intégrations MCP et Skills
Model Context Protocol (MCP) a permis à Kimi Code CLI de se connecter directement à des systèmes externes contenant les données du projet. Nous avons utilisé mcp Figma pour récupérer les design tokens, les données de mise en page et la typographie directement depuis Figma, réduisant ainsi la traduction manuelle entre design et code ; nous avons aussi connecté des outils internes afin d’exposer les tâches, les spécifications et les cas limites sans changer de contexte.
Ajouter un serveur tient en une seule commande :
Ce schéma se généralise à tout l’écosystème MCP. Pour vous inspirer, vous pouvez connecter des agents à :
Figma — MCP officiel pour le contexte de design, les variables et les données de mise en page issues du canvas
Atlassian Cloud — pages Confluence et éléments de travail Jira via le point d’entrée MCP distant d’Atlassian (documenté avec Rovo)
Bases de données, API de CMS — serveurs MCP de fournisseurs ou de la communauté ; les registres recensent des centaines d’options par catégorie
Votre stack peut être différente — API de documentation privée, service interne de design tokens ou data warehouse. L’idée reste la même : connecter l’agent aux systèmes qui détiennent déjà les données pertinentes. Pour les fichiers de configuration, les définitions de serveurs et les autres façons de câbler MCP dans Kimi Code CLI, consultez le guide de la plateforme.
Skill de revue
Nous avons également écrit un Skill pour la revue de code. Il s’agit d’un fichier de règles qui indique à Kimi Code CLI comment évaluer une merge request de bout en bout : lire le diff, retracer les fichiers et composants affectés, vérifier les violations du design system (couleurs brutes en dur, espacements hors grille, fallbacks d’accessibilité manquants), évaluer le risque par zone et générer un rapport structuré.
Le rapport suit un format fixe :
Un résumé de l’intention et du périmètre
Des constats regroupés par gravité (problèmes critiques bloquant le merge, améliorations recommandées, suggestions mineures de cohérence)
Pour chaque constat : preuves issues du diff, évaluation de l’impact et action concrète à mener
Le Skill signale aussi les risques potentiels pouvant nécessiter une validation rapide dans le navigateur ou sur appareil — les cas où l’agent est incertain mais où le coût de vérification reste faible.
En pratique, chaque PR de la refonte visuelle de moonshot.ai est passée par cette analyse structurée avant la fin de la revue. La sortie incluait toujours un rappel de l’intention, des constats classés par gravité, des preuves et des correctifs.
Cela a contribué à réduire les remaniements tardifs et à améliorer la cohérence du workflow Kimi Code, en faisant remonter des problèmes comme des URLs codées en dur à côté de constantes partagées, des champs d’analytics à aligner et des cas limites d’interaction mobile.
Ce qui nous a surpris
Pendant le refactoring, quelques schémas sont apparus alors qu’ils n’étaient pas évidents au départ.
Le passage des spécifications au code a été plus rapide que prévu
Avec Figma MCP et Kimi Code CLI dans le même fil, les dimensions et les design tokens arrivaient sous forme d’entrées structurées plutôt que d’être transcrits à la main. Résultat : des boucles d’itération plus courtes par section — les changements et corrections au niveau des propriétés étaient souvent intégrés en une seule passe, sans aller-retour entre outils.
Les prompts de recherche se sont révélés plus utiles que prévu
La refonte s’est largement appuyée sur de longues passes guidées par la documentation, parcourant la documentation d’exécution et les implémentations de référence aux côtés du dépôt. Garder ces éléments dans la même session que le code s’est souvent avéré aussi précieux que les modifications elles-mêmes.
Le Skill de revue a transformé les petites incohérences en liste exploitable
Le rapport structuré a fait remonter les mêmes catégories de problèmes que celles évoquées plus haut : URLs codées en dur à côté de constantes partagées, champs d’analytics à aligner et cas limites d’interaction mobile. La plupart étaient mineurs pris isolément, mais plus faciles à traiter une fois regroupés en une seule passe.
Les longs fils restaient faciles à reprendre
Des commandes comme kimi --continue et /compact évitaient de reconstruire le contexte chaque matin pour un travail étalé sur plusieurs jours. Cela a réduit le re-prompting et permis au même workflow Kimi Code d’avancer de façon régulière.
Pour en savoir plus sur la reprise de sessions, le passage de l’une à l’autre et la gestion du contexte avec /compact et les commandes associées, consultez le guide des sessions de Kimi Code CLI.
Leçons tirées de la reconstruction de moonshot.ai
Si nous devions refaire une refonte visuelle similaire de moonshot.ai, nous aborderions certains points différemment.
Commencer par le contexte, pas par le code
Consacrer la première heure à documenter le périmètre, les contraintes et les conventions a fait gagner plus de temps que n’importe quel prompt ultérieur. Poser ces bases dès le départ a permis à des outils comme Kimi Code CLI de se comporter de manière plus cohérente tout au long du workflow.
Connecter tôt une source de vérité
Dans notre cas, il s’agissait de Figma. Dans d’autres projets, cela pourrait être un CMS, une API interne ou un design system. L’essentiel est de garantir que le système travaille avec des données réelles plutôt qu’avec des hypothèses inférées, surtout lorsqu’on utilise un agent de codage IA dans un contexte de refactoring frontend.
Maintenir le design et le contexte de tâche dans la même boucle
Rassembler tokens, spécifications et implémentation dans un contexte partagé a réduit les allers-retours et stabilisé les cycles d’itération. C’est là que les workflows associant Figma MCP et Kimi Code CLI se sont montrés particulièrement efficaces, en aidant à garder l’intention de design et les changements de code alignés dans une boucle continue.
Si vous ne voulez pas écrire de code : Kimi Websites
Tout ce qui précède décrit un workflow centré développeur — terminaux, diffs et fichiers de contexte. Pourtant, le même résultat — un site web soigné et responsive — peut aussi être obtenu sans cette stack lorsque la vitesse compte davantage que le contrôle au niveau du framework.
Kimi Websites repose sur le même modèle Kimi K2.5, mais via une interface visuelle no-code. Vous décrivez ce que vous voulez en langage naturel, affinez les sections par la conversation et publiez en un clic. Il peut aussi prendre une capture d’écran existante en entrée et reconstruire la structure de la mise en page.
Pour les fondateurs qui prototypent des landing pages ou les marketeurs qui livrent des sites de campagne dans des délais serrés, c’est une voie plus rapide que de travailler directement avec une stack frontend traditionnelle.
Conclusion
Kimi Code CLI et Kimi K2.5 se sont révélés particulièrement utiles dans les parties du projet où l’ampleur comptait davantage que la complexité. Une refonte visuelle porte rarement sur des problèmes difficiles : elle implique surtout une multitude de petits changements qui doivent rester cohérents à l’échelle d’un système. C’est chronophage pour les humains, mais relativement bien adapté à un agent capable de retracer et de comparer des éléments entre plusieurs fichiers.
Nous avons néanmoins pris les décisions, relu chaque changement et validé le résultat final. L’agent a pris en charge le travail répétitif de traçage, de comparaison et de première revue. En pratique, cette répartition des rôles s’est avérée être une manière concrète d’intégrer un agent de codage IA dans un workflow de production. Pour les refactorings transverses, la vérification design-to-code et les travaux de cohérence à grande échelle, cette approche s’est montrée utile.