Comment fonctionne l'interface utilisateur pilotée par serveur et pourquoi elle simplifie la vie du front-end

Les équipes front-end se noient souvent dans des « petites versions » sans fin : changer l'ordre des blocs, le texte sur la bannière, lancer une promotion, puis à nouveau l'assemblage, les tests, le déploiement sur toutes les plateformes. Sur mobile, la modération du magasin est ajoutée, sur le Web, il y a le risque de casser ce qui fonctionnait hier. En conséquence, la vitesse du produit diminue et le développeur front-end se transforme en « correcteur manuel ».

Server-Driven UI (SDUI) change les règles : le serveur donne non seulement des données, mais aussi description de l'interface — quels composants rendre, dans quel ordre et avec quels paramètres. Le client devient un moteur de rendu stable qui comprend le contrat et assemble l'écran à partir de briques prêtes à l'emploi. Résultat : les modifications et les expériences arrivent immédiatement aux utilisateurs, sans mise à jour de l'application ni déploiements nocturnes inutiles.

Pourquoi est-ce nécessaire ? 🤔

• Modifications sans version : textes, ordre des blocs, bannières — tout change sur le serveur, l'utilisateur voit immédiatement.

• Tests A/B et indicateurs de fonctionnalité : différentes configurations pour les segments sans mise à jour des clients.

• Contrat unique pour iOS/Android/Web : moins de divergences entre les plateformes.

• Campagnes rapides : « l'écran du Nouvel An » est déployé en tant que configuration, et non en tant que nouvelle version.

À quoi ressemble le schéma SDUI

Le serveur renvoie la structure : layout (hiérarchie), la liste des composants avec type et props, les actions et les méta-informations (version, TTL, drapeaux).

{
  "version": "1.3",
  "page": "product",
  "layout": {
    "type": "Scroll",
    "children": [
      { "type": "Title", "props": { "text": "Best offer of the day" } },
      { "type": "Image", "props": { "src": "https://cdn/app/promo.jpg", "ratio": 1.6 } },
      {
        "type": "Card",
        "props": {
          "title": "Pro Headphones",
          "price": "7 990 ₽",
          "cta": { "type": "Action", "name": "buy", "params": { "id": "hp-2025" } }
        }
      }
    ]
  },
  "tracking": [{ "event": "view_product", "params": { "id": "hp-2025" } }]
}

Le client fait correspondre "type" → composant local : Title → <Title/>, Card → <ProductCard/>, etc.

Comment cela est-il exécuté sur le client ?

1. Nous obtenons le schéma (avec cache et version).

2. Nous validons (JSON Schema/Protobuf) et faisons un graceful-fallback en cas d'erreurs.

3. Mappage type sur les composants locaux via le registre.

4. Nous rendons et connectons les gestionnaires d'actions (navigation, API, suivi).

// Pseudo-code TypeScript
const registry = {
  Title: (p) => <Title {...p} />,
  Image: (p) => <Image {...p} />,
  Card:  (p) => <ProductCard {...p} />,
};

function renderNode(node) {
  const Component = registry[node.type] ?? Fallback;
  const children = (node.children || []).map(renderNode);
  return <Component {...(node.props||{})}>{children}</Component>;
}

Où le SDUI entre-t-il particulièrement 🎯

Avantages et inconvénients

• Avantages : modifications sans déploiement client, tests A/B rapides, cohérence entre les plateformes, personnalisation.

• Inconvénients : discipline du contrat et des versions, coûts du registre/validateurs/fallbacks, moins de « liberté visuelle » (résolu par des jetons de conception).

Erreurs fréquentes et comment les éviter

• Sans version : ajoutez version, prenez en charge plusieurs générations de schémas.

• Composants géants « universels » : gardez les blocs de granularité moyenne (Card, Banner, List).

• Pas de validation : JSON Schema/Proto + champs obligatoires et valeurs par défaut.

• Ignorer le cache : ETag/Last-Modified, TTL, stale-while-revalidate.

• Pas d'analyse : décrivez les événements dans le schéma et traitez-les de manière centralisée.

Quand le SDUI n'est pas nécessaire

• Écrans de mouvement ultra-créatifs et animations personnalisées denses.

• Les pages de destination promotionnelles à usage unique sont plus faciles avec les statiques/SSR.

• Des équipes où le « pixel parfait à tout prix » est plus important que l'échelle.

Mini exemple de schéma pour une campagne A/B

{
  "version": "2.0",
  "experiment": "hero_ab",
  "variant": "B",
  "layout": {
    "type": "Scroll",
    "children": [
      { "type": "Banner", "props": { "style": "bright", "text": "-20% today" } },
      { "type": "Grid", "props": { "cols": 2 }, "children": [
        { "type": "Card", "props": { "title": "Product A", "price": "1 990 ₽" } },
        { "type": "Card", "props": { "title": "Product B", "price": "2 190 ₽" } }
      ] }
    ]
  }
}

Conclusion 💡

SDUI transforme le frontend en rendu stable, et le produit - dans Constructeur d'écran rapide. Cela permet d'économiser des semaines de petites versions, d'accélérer les expériences et d'aligner l'UX sur toutes les plateformes. Si votre contenu change fréquemment ou si vous lancez des campagnes, SDUI est rapidement rentable.

Dans Codique nous rendons l'apprentissage de la programmation passionnant et compréhensible : nous avons des cours intéressants avec des tâches qui aident à améliorer les compétences étape par étape.

Et nous avons aussi un chaîne de télégram, où nous discutons d'idées intéressantes, partageons nos expériences et analysons ensemble les tâches, apprendre devient non seulement utile, mais aussi amusant.

Avez-vous essayé le SDUI ? Où a-t-il fonctionné, où a-t-il échoué et pourquoi ?