Développement web

Une agence de développement web pour Nyon et La Côte

Play Digital Sàrl conçoit des sites web et des applications web depuis Aubonne. Nous accompagnons les PME qui souhaitent présenter leur activité, proposer un service en ligne ou connecter leurs outils de gestion. Le projet commence par vos utilisateurs et vos contraintes : contenu, parcours, données et budget.

Un site de présentation, un espace client et un logiciel interne répondent à des besoins différents. Nous vous aidons à choisir le périmètre utile avant de développer, puis à préparer les tests, la mise en ligne et la maintenance.

Quel développement web pour votre entreprise ?

• Site internet sur mesure : présenter vos prestations, faciliter la prise de contact et publier un contenu accessible aux visiteurs et aux moteurs de recherche.
• Portail client ou plateforme SaaS : partager des documents, suivre un dossier et proposer un service en ligne.
• Logiciel métier, ERP ou CRM : centraliser vos opérations et relier les données de vos équipes.
• Application mobile iOS et Android : prolonger le service sur le terrain lorsque le navigateur ne suffit pas.

Des plateformes déjà développées en Suisse

Découvrez PharmOnline, plateforme de services pour les pharmacies, et RoliCar, marketplace automobile suisse. Ces réalisations décrivent le besoin, la solution et le périmètre livré.

Comment démarrer un projet web à Nyon ?

Présentez votre activité, les tâches à simplifier et vos outils actuels. Aucun cahier des charges complet n’est nécessaire pour un premier échange. Parlons de votre projet web pour identifier le bon point de départ.

La performance n'est pas une finition, c'est une contrainte de conception

On ne rend pas rapide une application lente : on la reconstruit. La vitesse se décide au moment de l'architecture — ce qui est rendu sur le serveur, ce qui part dans le navigateur, ce qui n'a jamais besoin d'exister.

C'est aussi une contrainte mesurable, et publique. Google évalue chaque site sur trois indicateurs, au 75ᵉ percentile des visites réelles sur 28 jours glissants — autrement dit sur l'expérience des trois quarts de vos visiteurs, pas sur un test de laboratoire :

• LCP — affichage du contenu principal : sous 2,5 s
• INP — réactivité aux interactions : sous 200 ms
• CLS — stabilité visuelle : sous 0,1

Ces seuils sont notre engagement de départ, pas un objectif à négocier en fin de projet.

Choisir la bonne quantité de JavaScript

La plupart des sites lents le sont pour une raison unique : ils envoient au navigateur un programme entier là où une page suffisait. Nous décidons page par page.

• Page statique — contenu éditorial, pages de présentation, articles. Rendu à la construction, servi tel quel. Rien à exécuter côté client.
• Rendu serveur — contenu personnalisé ou qui change à chaque visite. Le navigateur reçoit du HTML complet, il n'attend rien.
• Îlots interactifs — seuls les composants qui en ont besoin embarquent du JavaScript : un formulaire, un filtre, une carte. Le reste de la page n'en charge aucun.

Ce site en est l'illustration : il est construit avec Astro, et l'essentiel de ses pages ne charge aucun script applicatif.

Une application se juge sur cinq ans, pas sur sa mise en ligne

Le coût d'une application se concentre après la livraison. Trois choix pèsent plus que tous les autres :

1. Des types de bout en bout. TypeScript du modèle de données à l'interface. Un changement de schéma qui casse quelque chose le fait savoir à la compilation, pas en production six semaines plus tard.
2. Des tests qui décrivent des règles, pas des états. Un test qui affirme « la page d'accueil contient douze articles » se casse à chaque publication. Un test qui affirme « chaque article publié apparaît dans son index » tient.
3. Des dépendances qu'on peut retirer. Chaque bibliothèque est une dette future. Nous en prenons peu, choisies pour leur stabilité et leur sortie possible.

Mesurer la livraison, pas l'agitation

Nous suivons les quatre indicateurs de référence du programme DORA, qui distinguent les équipes qui livrent de celles qui s'activent : fréquence de mise en production, délai entre un commit et sa mise en ligne, part des livraisons qui provoquent un incident, temps de rétablissement.

Ils ont un intérêt inhabituel : ils ne récompensent pas la prudence. Une équipe qui livre rarement pour « limiter les risques » y apparaît comme ce qu'elle est — une équipe dont chaque livraison est un événement risqué.

Reprendre l'existant plutôt que tout refaire

Une refonte totale est presque toujours le mauvais choix : elle gèle l'évolution pendant des mois et rejoue les mêmes erreurs sur une technologie plus récente. Nous préférons isoler ce qui pose problème, le remplacer derrière une interface stable, et laisser le reste en place tant qu'il rend service. Un système qui fonctionne mérite mieux qu'une réécriture par principe.