Choisissez une application de bureau lorsque l’architecture proposée est centrée sur des ordinateurs spécifiques et que la fiabilité du fonctionnement local est prioritaire. Choisissez un système métier basé sur le web lorsque la conception proposée doit donner à plusieurs personnes accès à des données partagées, à des contrôles fondés sur les rôles et à une supervision opérationnelle depuis plusieurs sites. Aucun format ne permet de résoudre un flux de travail mal défini : déterminez donc comment les données doivent circuler avant de décider où l’interface doit s’exécuter.
Logiciels de bureau ou systèmes métier basés sur le web : le choix fondamental
Une conception courante de logiciel de bureau utilise une application installée sur un ou plusieurs ordinateurs, avec des formulaires, un stockage local, des fonctions d’importation et d’exportation ainsi que des rapports inclus dans le périmètre convenu. Cette approche peut convenir à un flux de travail effectué principalement depuis un poste fixe ou au sein d’une équipe étroitement gérée. Demandez au fournisseur de confirmer si l’architecture de bureau proposée est uniquement locale, connectée à un service partagé ou dépendante d’une autre base de données. Consultez le périmètre du développement de logiciels de bureau si ces exigences correspondent à votre activité.
Une conception courante de système métier basé sur le web fournit un accès par navigateur et utilise un service de données partagé, mais l’architecture proposée peut varier. Demandez au fournisseur où les données sont stockées, comment les utilisateurs se connectent et si le système prend en charge le travail local ou hors ligne. Ce format peut convenir aux flux de travail dans lesquels les collaborateurs créent, consultent et mettent à jour les mêmes données, tandis que les responsables ont besoin de permissions, de tableaux de bord et d’exportations. Le développement de logiciels métier couvre, comme périmètre initial, la cartographie des flux de travail, un modèle de données, les modules principaux, les rôles, un tableau de bord, les exportations, les sauvegardes et l’accompagnement des équipes. Confirmez lesquels de ces éléments doivent faire partie de votre projet au lieu de supposer que toutes les fonctionnalités sont incluses.
La distinction est architecturale et ne constitue pas une règle concernant ce que chaque format peut ou ne peut jamais faire. Les applications de bureau peuvent se connecter à des services partagés, et les systèmes web peuvent prendre en charge certaines activités hors ligne s’ils sont conçus spécifiquement à cette fin. Les deux choix peuvent nécessiter un hébergement, des travaux de sécurité, des sauvegardes et des mises à jour continues, selon la conception convenue.
Quand le stockage local, l’importation, l’exportation et les flux hors ligne sont importants
Commencez par identifier le point où une feuille de calcul échoue. Un collaborateur saisit-il régulièrement des données sur un poste fixe, importe-t-il des fichiers provenant d’équipements ou de fournisseurs, produit-il un rapport puis transmet-il une exportation ? Si la tâche peut être effectuée sans qu’une autre personne modifie le même enregistrement, une application de bureau peut maintenir le flux de travail proposé à un niveau de complexité réduit.
Précisez les ordinateurs et les systèmes d’exploitation utilisés, les formats de fichiers et les fichiers d’exemple, les règles de validation, les formats de rapports ainsi que les fonctions qui doivent fonctionner sans connexion. Demandez où les données locales seront stockées, qui pourra y accéder, comment elles seront sauvegardées et comment elles pourront être restaurées sur un ordinateur de remplacement. Un simple bouton d’exportation ne constitue pas un plan de récupération : faites de la sauvegarde et de la restauration des contrôles d’acceptation proposés, et demandez au fournisseur d’expliquer comment ils seraient testés.
Si les collaborateurs doivent continuer à travailler hors ligne puis synchroniser les données ultérieurement, documentez ce qui se passe lorsque deux personnes modifient le même enregistrement. La synchronisation hors ligne constitue une exigence distincte, que l’interface soit de bureau ou web. Le guide des exigences pour une conception offline-first peut aider à formuler des questions sur les modifications mises en file d’attente et les conflits.
Quand l’accès partagé, les rôles et les tableaux de bord sont importants
Un système basé sur le web peut être plus pertinent lorsque des collaborateurs situés sur différents sites ont besoin d’un enregistrement commun, lorsque des superviseurs approuvent des modifications ou lorsque des responsables ont besoin d’une vue du travail en cours. Décrivez chaque rôle en fonction des actions : qui peut créer, modifier, approuver, exporter, supprimer ou consulter des champs sensibles ? Déterminez si le tableau de bord doit afficher l’état opérationnel en temps réel, des totaux périodiques ou les deux, et définissez chaque indicateur à partir des enregistrements sous-jacents.
Demandez comment le système proposé identifiera les utilisateurs, enregistrera les modifications importantes et gérera une perte de connexion. Demandez également où l’application et la base de données fonctionneront, qui les administrera et comment les accès seront supprimés lorsqu’une personne quittera l’organisation. L’accès par navigateur ne garantit pas à lui seul des permissions appropriées, et un tableau de bord n’est utile que lorsque ses chiffres correspondent aux définitions convenues par l’équipe.
Exigences à transmettre à un studio de développement
Fournissez des exemples réels et anonymisés des formulaires, feuilles de calcul et rapports utilisés actuellement par l’équipe. Demandez ensuite à chaque studio de montrer comment sa proposition répond aux mêmes contrôles d’acceptation :
| Exigence à spécifier | Ce que le fournisseur doit montrer |
|---|---|
| Cycle de vie d’un enregistrement : création, modifications, approbation et clôture | Présenter un enregistrement d’exemple du début à la fin, y compris les exceptions et les corrections. |
| Données existantes et échange de fichiers | Importer un échantillon représentatif, identifier les lignes rejetées et exporter les données dans un format convenu. |
| Rôles et champs sensibles | Se connecter avec chaque rôle et tenter des actions autorisées et interdites. |
| Définitions des rapports | Rapprocher un exemple de tableau de bord ou de rapport avec les enregistrements sous-jacents. |
| Travail hors ligne et récupération | Déconnecter un appareil pour les tâches convenues, puis démontrer la reconnexion ou la restauration d’une sauvegarde, selon le cas. |
| Environnement d’exploitation | Installer ou déployer une version de test dans l’environnement prévu et documenter ce que l’acheteur doit maintenir. |
Indiquez le nombre d’utilisateurs et de sites prévus, mais demandez aux fournisseurs d’expliquer comment leur conception répond à ces exigences au lieu d’accepter une affirmation de capacité non étayée. Incluez toute base de données existante, intégration avec des appareils ou processus que le nouveau système doit conserver.
Comment comparer le périmètre, la remise et les plans de déploiement
Comparez les devis sur la base du même flux de travail et des mêmes cas de test. Séparez les travaux essentiels des améliorations facultatives et vérifiez si chaque proposition inclut la migration des données, les permissions, les rapports, les tests avec vos données d’exemple, le déploiement et l’accompagnement des équipes. Précisez qui fournit l’environnement d’hébergement ou les ordinateurs, et qui est responsable des mises à jour et des sauvegardes après le lancement.
Demandez par écrit les livrables de remise et confirmez exactement ce que le fournisseur propose de fournir. Les périmètres répertoriés pour les logiciels de bureau et les logiciels métier incluent le code source et la documentation, mais la remise finale doit tout de même identifier l’installateur ou les instructions de déploiement spécifiques, le schéma de données, les détails de configuration, les accès administrateur et la documentation utilisateur nécessaires à votre projet.
La centralisation du déploiement peut faciliter la distribution des modifications dans certaines architectures, tout en introduisant des dépendances liées à l’hébergement, à la connectivité ou aux opérations. Demandez au fournisseur d’expliquer ce compromis pour la conception proposée, notamment qui applique les mises à jour, comment les modifications sont testées et ce qui se passe en cas d’échec d’une mise à jour.
Utilisez une installation ou un déploiement vierge, une restauration de sauvegarde et une exportation de données comme contrôles d’acceptation proposés côté acheteur lorsqu’ils correspondent à vos exigences. Ces contrôles doivent être inscrits dans l’accord de projet s’ils sont importants ; ils ne constituent pas des livrables confirmés à moins que le fournisseur ne les inclue explicitement. Avant l’acceptation, demandez au fournisseur de démontrer les contrôles convenus avec des données représentatives. Pour un système existant, précisez s’il s’agit d’un remplacement, d’une intégration ou d’une mise à niveau progressive afin que les estimations couvrent la même tâche.
FAQ
Un logiciel de bureau peut-il prendre en charge plusieurs utilisateurs ?
Oui, mais l’utilisation partagée nécessite une conception définie. Demandez si chaque installation conserve des enregistrements distincts ou se connecte à une base de données partagée, comment les modifications simultanées sont gérées et ce qui se passe lorsque le réseau est indisponible. Ne supposez pas que la copie d’un fichier de données local entre plusieurs ordinateurs assure une collaboration fiable.
Un système basé sur le web est-il automatiquement plus facile à maintenir ?
Non. Une architecture web peut modifier la manière dont les mises à jour sont distribuées, mais l’application, la base de données, l’hébergement, les contrôles d’accès et les sauvegardes doivent toujours avoir un responsable. Comparez les responsabilités de maintenance proposées, le processus de test et la procédure de récupération au lieu de considérer le mode d’accès comme une garantie de maintenance.
Devons-nous migrer chaque colonne de nos feuilles de calcul ?
Uniquement après avoir vérifié la signification de chaque colonne et déterminé si elle est encore utilisée. Identifiez les doublons, les valeurs incohérentes et les formules qui représentent des règles métier. Convenez d’un échantillon de migration et vérifiez les enregistrements et les rapports obtenus avant d’approuver une importation complète.
Pour un cahier des charges de projet comparable, partagez le flux de travail actuel et des fichiers d’exemple, les rôles et rapports requis, le nombre prévu d’utilisateurs et de sites, les systèmes d’exploitation ou contraintes d’hébergement, les besoins hors ligne, les intégrations existantes et la destination des données exportées. Incluez les détails de tout logiciel remplacé, puis discutez des exigences afin de confirmer le périmètre et les responsabilités de livraison.