Novemade

Comment nous construisons

11 produits. Un seul système de production partagé.

11 produits ne tiennent pas côte à côte si les parties coûteuses ne sont pas partagées. Recherche, production, sortie et mesure passent par un système interne unique, de sorte que le cinquième produit coûte moins cher à lancer que le premier et qu’il est mieux informé au moment de sortir.

La boucle

9 étapes, et la dernière alimente la première.

Chaque produit parcourt le même circuit. Les étapes portent le nom de ce qui s’y passe, et c’est pourquoi apprendre quelque chose et agir en conséquence font deux étapes et non une.

  1. 01RechercheDes signaux et une banque d’idées par produit, notés selon leur pertinence avant que quoi que ce soit ne soit fabriqué.
  2. 02DesignLe produit décide de sa voix, de ses affirmations et de ses limites. Le système les remplit.
  3. 03FabricationRessources, voix off et sous-titres, assemblés à partir du matériau propre à chaque produit.
  4. 04LocalisationChaque chaîne dans chaque langue, la parité entre catalogues étant vérifiée plutôt que supposée.
  5. 05TestDes contrôles automatiques, puis une personne. Rien n’atteint une file sans relecture.
  6. 06PublicationUn empaquetage par plateforme, la publication restant volontairement derrière une approbation humaine.
  7. 07MesureLes signaux de sortie et de performance reviennent là où le travail a été fait.
  8. 08ApprentissageCe qui a marché sur un produit est lisible par le suivant qui le demande.
  9. 09AméliorationLe correctif atterrit dans le système partagé, pas dans la copie d’un seul produit.

Ce que le système garantit

L’automatisation n’est utile que si on peut la relancer sans danger.

L’essentiel du travail dans un système de production n’est pas de fabriquer. C’est de garantir qu’un réessai, un plantage ou un déclenchement en double ne puisse rien casser — ce qui permet au reste d’être automatique.

Rien ne se publie deux fois

Les tâches de contenu et de publication sont identifiées par des hachages déterministes de leurs propres entrées. Un déclenchement en double, un réessai ou un plantage suivi d’un redémarrage se résolvent vers la même identité : le système ne peut donc ni rendre ni publier deux fois.

Réessayer est toujours sans risque, et c’est ce qui rend l’automatisation redémarrable.

Un plantage reprend, il ne redémarre pas

Chaque étape enregistre son résultat avant que la suivante ne commence. Une panne à mi-chemin repart de la dernière étape terminée au lieu de refaire le travail coûteux qui la précède.

Un long pipeline peut échouer sans coûter toute l’exécution.

Le système n’apprend jamais le nom d’un produit

Tout ce qui varie d’un produit à l’autre — voix, familles de contenu, emplacement des ressources, règles sur ce qui ne doit jamais être affirmé — vit dans la configuration de ce produit. Le code partagé la lit et ne référence jamais un produit directement.

Un nouveau produit est une configuration, pas un fork.

La répétition est mesurée, pas espérée

Chaque pièce porte une empreinte de son sujet, de son accroche et de son script. Le travail nouveau est comparé à l’historique récent de ce produit et rejeté s’il en est trop proche, ce qui renvoie le générateur chercher un autre angle.

Du volume, sans un flux qui sonne comme un produit se parlant à lui-même.

Les échecs sont classés, pas avalés

Les appels externes sont réessayés avec un délai borné et triés en passagers, permanents et non configurés. Une plateforme pas encore configurée est un avertissement normal, jamais un plantage et jamais un saut silencieux.

La différence entre cassé et pas encore branché est toujours visible.

Les contrôles qualité passent avant qu’un humain regarde

La production générée est vérifiée automatiquement avant d’atteindre une file, y compris sur le point de savoir si chaque scène a utilisé du vrai matériau produit plutôt qu’un substitut. Ce qu’une personne relit a déjà passé les tests mécaniques.

Le temps de relecture va au jugement, pas à la chasse aux fautes évidentes.

Les bugs deviennent des tests, pas du folklore

Les pannes gênantes — un gabarit qui massacre un sujet déjà formulé en question, une amorce qui double un préfixe — ont été trouvées en générant de vraies sorties et en les lisant, puis fixées par un test de régression.

La même classe d’erreur ne peut pas revenir en silence.

Une langue est livrée entière ou n’est pas proposée

Les catalogues sont vérifiés en parité avec la langue de référence avant qu’un build passe, de sorte qu’une langue ne peut pas sortir avec la moitié de ses clés et une phrase en anglais au milieu d’un écran. Là où une langue demande plus que du texte — une mise en page de droite à gauche, un mot composé plus long, une voix enregistrée — cela aussi est vérifié, à l’écran et non dans le fichier.

Dix, seize ou vingt-neuf langues, et dans aucune un écran à moitié traduit.

Chaque ressource générée sait ce qui l’a faite

Les ressources produites par un modèle portent le modèle, sa révision exacte, sa licence et l’ensemble de candidats dont elles ont été tirées, stockés à côté du fichier. L’audio enregistré porte son moteur, sa licence et la mesure sur laquelle son propre contrôle qualité l’a noté. Un jeu de captures porte un hachage par fichier.

Une question de licence des années plus tard est une recherche, pas une enquête.

L’approbation humaine reste dans la boucle

Le système prépare, empaquette et propose. Une personne approuve. La publication n’est jamais entièrement autonome, par conception et non par omission.

De l’échelle, sans céder le contrôle éditorial.

Vérifiez vous-même

Ce site est construit avec la même discipline

Plutôt que de décrire le standard, voici ce qui est imposé sur la page que vous lisez en ce moment.

  • 01Une seule définition de marque génère chaque marque, icône, favicon et carte sociale distribuable. Rien n’est exporté à la main.
  • 02Le pipeline de ressources refuse une capture sans légende, de sorte qu’aucune image ne peut sortir sans texte alternatif.
  • 03Le build échoue si un produit revendique une fiche de boutique qu’il n’a pas, ou si un nombre de téléchargements, une note ou un nombre d’utilisateurs apparaît quelque part dans le contenu.
  • 04Le contraste des couleurs est calculé dans un test contre chaque surface sur laquelle il est peint, dans les deux thèmes.
  • 05Un harnais de navigateur charge chaque route à huit largeurs et échoue en cas de débordement horizontal, de menu mobile effondré ou de menu qui refuse de se fermer.
  • 06Les liens internes sont parcourus à chaque vérification, de sorte qu’un renommage ne peut pas laisser discrètement un lien mort derrière lui.
  • 07Chaque nombre que ce site énonce sur son propre catalogue est calculé depuis le catalogue au moment du build. Un test fait échouer le build si l’un d’eux est écrit à la main dans une phrase.
  • 08Chaque produit doit avoir une démo qui fonctionne, et c’est vérifié plutôt que supposé — ajouter un produit sans démo fait échouer le build.
  • 09Un produit ne peut afficher l’étiquette « en ligne » que si son état de boutique indique une fiche publique, et seule une fiche publique peut produire un bouton de téléchargement.

La limite

Ce que nous ne publions pas

Cette page décrit ce que fait le système et ce qu’il produit. Elle ne décrit pas comment il est déployé. Hôtes, points d’accès, identifiants, noms de machines, chemins de stockage et architecture de sécurité restent privés — non pas parce qu’ils sont intéressants, mais parce que les publier serait négligent. Le site public et les systèmes internes ne partagent aucun identifiant et aucun chemin de contrôle.