Un site précis. Une application qui tient son rôle.

Le développement sur mesure commence par les rôles : qui publie, qui saisit, qui consulte et qui décide. Une page publique doit aider un visiteur à comprendre l’offre ; un portail doit aider une personne identifiée à accomplir une tâche. Les mélanger peut exposer des informations privées ou imposer inutilement un compte à quelqu’un qui souhaite seulement lire.

Pour un site public, nous travaillons la hiérarchie des contenus, la typographie et la navigation. Lorsqu’un portail ou un outil métier est nécessaire, le cadrage précise aussi qui peut consulter une information, quelles actions sont permises et comment le site communique avec les systèmes existants. Ces choix deviennent des points concrets à examiner sur la maquette, puis sur l’application réalisée.

Un cadrage utile produit un inventaire de contenus, un parcours principal, les rôles concernés et des critères d’acceptation. Par exemple, une demande reçue doit pouvoir être retrouvée par la bonne équipe sans être visible d’un autre client. Cet exemple est plus vérifiable qu’une exigence générale de plateforme « intuitive » ou « sécurisée ».

La construction proposée avance par livrables examinables, d’abord sur des données synthétiques. La revue doit porter sur le résultat, mais aussi sur une saisie incorrecte, un accès interdit et une interruption. Les vérifications automatiques aident ; elles ne remplacent pas l’examen visuel, la navigation au clavier et l’usage sur un téléphone réel.

Le calendrier dépend du contenu disponible, des interfaces partenaires et des décisions encore ouvertes. La mise en service demande son propre accord sur l’hébergement, les responsabilités et les procédures de reprise. Une version de démonstration ne vaut pas mise en production sur l’infrastructure définitive.

Choisir l’environnement d’exploitation implique aussi de définir où résident les documents, les journaux et les sauvegardes, qui maintient l’application et comment revenir sur une modification défaillante. Ces choix doivent rester compréhensibles pour l’organisation utilisatrice. Un site public et une application contenant des dossiers confidentiels ont des besoins différents. Le plan de livraison précise cette distinction et prévoit une passation pratique, avec des responsabilités identifiées et les accès nécessaires pour faire fonctionner le service dans la durée.

Les parcours privés demandent un contrôle des droits côté système, des essais d’isolation et une politique de documents adaptée. Vedetta, destiné à toutes les professions concernées par la vigilance à Monaco, reste en développement. Sa future intégration dans un outil métier constitue un périmètre à planifier, sans approbation automatique des relations ni garantie juridique.

Un cabinet peut avoir besoin d’un suivi de dossiers ; une agence, d’une publication maîtrisée de ses annonces ; une entreprise, d’un espace de demandes internes. Ces exemples appellent des parcours distincts. L’étude doit vérifier si une adaptation d’un outil existant répond au besoin avant de financer une nouvelle plateforme.

La reprise future doit être préparée : documentation, dépendances, comptes, données exportables et droits sur le code se définissent contractuellement. L’exploitation doit nommer un responsable des incidents, des mises à jour et des évolutions. Le choix de technologies connues facilite une passation, mais ne remplace ni cette documentation ni un test de reprise.