Intégrer une application tierce dans un décodeur : les contraintes qu'on n'a pas sur le web

Voici une situation qui se répète assez souvent pour être devenue prévisible. Une équipe livre une application web soignée, testée, rapide sur un portable et fluide sur un téléphone. On la déploie sur un décodeur. Elle rame, elle saccade, elle finit par se fermer toute seule. Personne n'a écrit de mauvais code — l'application est simplement conçue pour un environnement qui n'existe pas ici.

Les contraintes du décodeur ne sont pas des versions atténuées de celles du web. Ce sont d'autres contraintes. Voici les cinq qui coûtent le plus cher quand on les découvre tard.

Le budget mémoire n'est pas le vôtre

Un décodeur dispose d'une quantité de mémoire modeste, et l'application n'en reçoit qu'une part. Le reste est déjà réservé: le middleware, le guide de programmation, les tampons du décodeur vidéo — qui sont volumineux et non négociables, parce que c'est ce qui empêche l'image de figer.

Quand le budget est dépassé, il n'y a pas de dégradation progressive comme sur un ordinateur qui commence à échanger avec le disque. Le système récupère la mémoire en fermant l'application. L'abonné voit son écran revenir brutalement à la télévision, sans explication.

Trois causes reviennent constamment. Les images chargées à leur pleine résolution pour être affichées en vignette: sur un catalogue de plusieurs centaines d'affiches, ça suffit à tout faire tomber. Les listes non virtualisées, qui construisent un nœud du document par élément au lieu de recycler les quelques éléments réellement visibles. Et les écouteurs d'événements jamais retirés, qui retiennent des vues entières bien après qu'on ait quitté l'écran — invisible sur une session de deux minutes en développement, fatal sur une session de deux heures chez l'abonné.

Rien n'est composé gratuitement

Sur un poste de travail, on prend l'accélération graphique pour acquise. Une ombre portée, un flou d'arrière-plan, une transition sur une propriété quelconque: la carte graphique absorbe tout sans qu'on y pense.

Sur un décodeur, la puissance graphique est dimensionnée pour afficher une interface et décoder de la vidéo, pas pour recomposer la page à chaque image. La règle pratique est stricte: on anime transform et opacity, et rien d'autre. Animer une position, une largeur ou une couleur de fond force un recalcul de mise en page à chaque image, et le résultat se voit immédiatement — une liste qui défile par saccades au lieu de glisser.

Les effets coûteux méritent une mention particulière. Un flou d'arrière-plan est presque gratuit sur un téléphone récent et catastrophique sur un boîtier d'entrée de gamme. Comme le parc est hétérogène, la décision ne peut pas se prendre sur le modèle le plus performant: elle se prend sur le plus faible boîtier encore en service, qui restera en service plus longtemps qu'on ne l'espère.

Le cycle de vie ne vous appartient pas

Une page web décide en gros de son propre sort: elle vit tant que l'onglet est ouvert. Une application de décodeur vit tant que le middleware le veut bien.

Elle peut être mise en arrière-plan parce que l'abonné a appuyé sur une touche qui ramène à la télévision en direct. Elle peut être suspendue parce qu'un appel entrant du système la déprioritise. Elle peut être purement et simplement terminée pour libérer de la mémoire, sans qu'aucun code de fermeture ne s'exécute.

La conséquence pratique est simple à formuler et souvent ignorée: on sauvegarde l'état au fur et à mesure, jamais à la fermeture. La position de lecture, le filtre choisi, l'endroit du catalogue où on était rendu — tout ça se persiste au moment où ça change. Une application qui attend un événement de sortie pour sauvegarder perdra régulièrement l'état de l'abonné, et le rapport de bogue sera irreproductible en laboratoire.

La vidéo n'appartient pas à la page

C'est la surprise la plus déstabilisante pour un développeur web, et celle qui casse le plus de maquettes.

Sur beaucoup de décodeurs, la vidéo n'est pas dessinée dans la page. Elle est décodée par un circuit dédié et affichée sur un plan graphique distinct, physiquement situé derrière l'interface. L'élément vidéo dans le document n'est souvent qu'un rectangle transparent qui indique au matériel où placer l'image. Le navigateur ne voit jamais les pixels de la vidéo.

Tout ce qui suppose le contraire échoue. On ne peut pas appliquer un filtre CSS sur la vidéo, ni la masquer avec un contour arrondi, ni la dessiner dans un canevas pour en extraire une vignette, ni superposer un élément semi-transparent en espérant que la vidéo transparaisse correctement. Les superpositions doivent être opaques, ou occuper une zone où la vidéo n'est pas.

Ce n'est pas une limitation arbitraire: c'est ce qui permet à un boîtier bon marché d'afficher de la haute définition sans y consacrer de puissance de calcul. Mais ça veut dire qu'une maquette approuvée avec un dégradé élégant par-dessus l'image du lecteur devra être revue, et mieux vaut le savoir avant la présentation au client.

La certification, qui n'est pas un problème technique

Une application prête n'est pas une application déployée. Elle doit passer une certification: conformité fonctionnelle, tenue en mémoire sur de longues sessions, performance mesurée sur chaque modèle de boîtier du parc, comportement au retour de veille, accessibilité, respect des règles de navigation par télécommande.

Le délai n'est pas technique, il est procédural — et c'est justement pourquoi il surprend les équipes qui planifient comme sur le web, où l'on déploie plusieurs fois par jour. Ici, une correction d'une ligne repasse par le même cycle qu'une refonte. La bonne réponse n'est pas d'essayer d'aller plus vite, c'est de regrouper les changements et de tester sur du vrai matériel très tôt, plutôt que sur un émulateur qui n'a ni la mémoire, ni le processeur, ni le plan vidéo du boîtier réel.

Développer pour décodeur ressemble finalement moins au développement web qu'au développement embarqué: des ressources connues à l'avance, un environnement qu'on ne contrôle pas, et un cycle de livraison lent. Le vocabulaire est celui du web; les réflexes doivent être ceux de l'embarqué.