Service:Service

Applications web Angular & React

SPAs performantes, design system cohérent, gestion d'état claire et mesure des performances utilisateurs réelles.

Ce que nous livrons

Design system réutilisable
Gestion d'état pragmatique
Accessibilité AA
Core Web Vitals optimisés

AngularReactDesign System

Discuter de ce besoin Voir des réalisations

Une application web moderne échoue rarement sur la technique. Elle échoue parce que trois développeurs ont écrit trois boutons différents, parce que la page met quatre secondes à devenir utilisable sur le téléphone du directeur commercial, ou parce que personne n'a pensé à ce qui se passe quand le réseau tombe au milieu d'un formulaire de douze champs.

Nous travaillons en Angular et en React. Le choix entre les deux se fait sur votre contexte et pas sur nos préférences : Angular quand l'équipe est grande ou tourne, parce que ses conventions imposées évitent que chacun invente les siennes ; React quand l'équipe est petite et expérimentée, parce que sa liberté devient alors un avantage. Si vous avez déjà l'un des deux en interne, la question est réglée, et nous ne viendrons pas vous expliquer que l'autre était mieux.

Comment nous travaillons

Un design system, ou juste des composants

La différence n'est pas cosmétique. Une bibliothèque de composants, c'est du code réutilisable. Un design system, c'est du code réutilisable plus les décisions écrites qui disent quand utiliser quoi : quel bouton pour une action irréversible, quel espacement entre deux blocs, ce qu'on affiche quand une liste est vide. Sans ces décisions, la bibliothèque dérive en six mois et on retrouve quatre nuances de gris dans la même page.

Nous livrons donc les deux : les composants, et le document qui explique les règles. Ce document tient rarement plus de dix pages. Sa valeur ne vient pas de son épaisseur mais du fait qu'il tranche : il dit non à des choses. Un système qui autorise tout ne sert à rien.

La gestion d'état, là où les projets se perdent

La plupart des applications n'ont pas besoin d'un magasin d'état global. Elles ont besoin de savoir où vit chaque donnée et qui a le droit de la modifier. Notre règle par défaut est simple : l'état reste le plus près possible de l'endroit qui l'utilise, et ne remonte que quand deux branches éloignées de l'interface en ont réellement besoin en même temps.

Quand un magasin global devient nécessaire, nous le mettons en place tardivement et sur un périmètre nommé. Les signaux d'Angular et les outils légers côté React couvrent aujourd'hui la majorité des cas sans la cérémonie des architectures Redux d'il y a huit ans. Sortir l'artillerie dès le premier jour produit des applications où lire une donnée demande de traverser quatre fichiers, et c'est un coût qu'on paie à chaque évolution pendant toute la vie du produit.

Les Core Web Vitals ne sont pas un caprice de Google

Ces trois mesures traduisent en chiffres ce que vit l'utilisateur : le temps avant de voir le contenu principal, la stabilité visuelle de la page pendant son chargement, et le délai avant que le clic réponde. Ce sont les trois moments où l'on perd quelqu'un. Google s'en sert pour classer, mais il aurait fallu s'en occuper même sans lui.

Nous mesurons sur les visiteurs réels et pas seulement en laboratoire, parce que les deux ne racontent pas la même histoire. Un score de 95 sur une machine de développeur en fibre ne dit rien de l'expérience d'un commercial en 4G dans un parking souterrain. L'accessibilité AA suit la même logique : la navigation au clavier, les contrastes et les intitulés de champs profitent d'abord à des gens qui n'ont aucun handicap, dans un train, avec une main occupée.

Ce qui amène ici

Chaque nouvelle page prend plus de temps que la précédente, alors que l'équipe n'a pas changé.
L'application est lente sur mobile et personne n'a de chiffre pour dire à quel point.
Vous avez quatre boutons primaires différents dans l'application, et trois façons d'afficher une erreur.
Un audit d'accessibilité est demandé par un client public ou un grand compte, et vous partez de zéro.

Quand ce n'est pas la bonne prestation

Si votre besoin est un site vitrine de six pages qui changera deux fois par an, une application web est le mauvais outil. Un site statique coûtera trois fois moins cher, se chargera plus vite et ne demandera aucune maintenance de dépendances. Nous vous orienterons vers cette solution, même si elle représente pour nous une prestation plus courte.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.

Discuter de ce besoin Voir les réalisations