Biologistes, un projet bio-informatique ? Formuler un bon cahier des charges est une des premières étapes vers la réussite ! (2/3)

Si vous aviez manqué la première partie, elle est disponible ici : https://infobioco.com/biologiste-formuler-un-cahier-des-charges-partie1/

Nous nous étions attardés sur les principaux éléments à prendre en compte dans la rédaction de ce dernier, avec notamment un focus sur la partie des fonctionnalités. Nous allons dans cette deuxième partie attaquer la base de données !

La base de données

Prévoir l’organisation de la base de données est l’étape incontournable lors de la lecture d’un CDC. Réussir à établir cette base de données permet d’optimiser le développement futur. En effet, prévoir la base de données en amont évite de nombreuses modifications ou adaptations de cette dernière lors du développement, la mise en place de scripts de migrations …, qui peuvent également demander des modifications de fonctionnalités existantes.

De plus, une base de données établie clairement aide grandement à la compréhension du fonctionnement de l’application, nous permettant, dans notre accompagnement/développement, de proposer les solutions toujours les plus adaptées.

L’établissement de la base de données se fait régulièrement à partir des différentes fonctions présentes dans l’application.

Afin de prévoir son organisation, IBC cherche dans un premier temps à obtenir la liste de l’ensemble des données de l’application et leur description. La manière la plus optimisée de décrire les données de l’application est de les présenter sous forme d’entités et de leurs attributs. Une entité correspond à une table de la base de données. Chaque table correspond à un tableau en deux dimensions dans lequel les lignes sont des enregistrements et les colonnes des attributs.

Ex : Dans une application avec connexion, l’utilisateur est une entité (table « utilisateur »). Cependant un utilisateur possède plusieurs informations (attributs) comme un login, un mot de passe, un nom, un prénom, une entreprise, une adresse mail et un numéro de téléphone.

Pour optimiser le développement de l’application avant même de commencer à coder, IBC cherche ensuite, pour chaque attribut, à déterminer les informations suivantes :

· Type de données (chaine de caractère, nombre, nombre à virgule…)

· La longueur maximum de l’attribut (dans le cas d’un nombre à virgule, préciser le nombre de chiffre avant et après la virgule)

· Est-il obligatoire ou facultatif ?

· Description de l’attribut si besoin

Ces informations sont directement corrélées au fonctionnement de l’application. Par exemple, savoir qu’un attribut est obligatoire pour une entité nous permet de savoir qu’à la création de cette entité lors de l’utilisation de l’application, il sera obligatoire pour l’utilisateur de remplir cette information pour valider le formulaire.

Ex : Inscription d’un utilisateur : Nous savons qu’un utilisateur a besoin d’un login et d’un mot de passe pour se connecter à l’application (= attributs obligatoires pour l’entité utilisateur). De ce fait, lors de l’inscription, à minima, ces deux informations seront obligatoires.

Dans un second temps, IBC cherche à comprendre quels sont les liens éventuels entre les tables de la base de données. Dans l’exemple un « utilisateur » fait partie d’une entreprise mais d’autres utilisateurs font également partie de la même entreprise. Cela signifie que dans la base de données en plus de la table utilisateur il existe une table entreprise et ces deux tables sont liées. Enfin, il faut préciser le type d’association. Un utilisateur doit faire partie d’une seule entreprise et à l’inverse une entreprise regroupe aucun, un ou plusieurs utilisateurs. De manière concrète, dans notre exemple nous dirons qu’un « utilisateur » fait partie d’une seule « entreprise » et une « entreprise » regroupe un à plusieurs « utilisateurs ».

Avec cet ensemble d’informations, il nous est possible de créer un schéma de la base de données relationnel.

Ex :

Les Id sont des attributs uniques nommées clé primaire présents dans chaque table et attribués automatiquement. Ici l’attribut « Entreprise » de la table utilisateur est ce que l’on appel une clé externe. Il correspondra à un Id_entreprise et permettra de faire le lien entre les deux tables.

Optimiser les relations entre les tables permet d’une part de créer une base de données la moins lourde possible (une information est présente une seule fois dans une seule table) et d’autre part, lors du développement de l’application, de créer des requêtes de récupération et d’envoi de données vers la base de données les moins lourdes possibles optimisant ainsi la vitesse d’exécution.

Après vous avoir donné certaines des clés pour bien appréhender votre base de données dans la rédaction d’un cahier des charges, nous étudierons les pages de votre application dans notre prochain article. Le design et les fonctions qu’elles doivent comporter permettront aux utilisateurs de l’application/logiciel d’en utiliser tout le potentiel ! Stay tuned !

Biologistes, un projet bio-informatique ? Formuler un bon cahier des charges est une des premières étapes vers la réussite ! (1/3)

Chez IBC, proposant un service sur mesure pour les biologistes, nous nous référons au CDC (=Cahier des Charges) de nos clients pour déterminer la technologie, la méthode de développement, le temps nécessaire …

Nous souhaitons ici vous présenter la méthodologie utilisée par IBC et plus généralement par un informaticien pour établir une stratégie de développement à partir d’un CDC.

👉 A la réception d’un CDC, notre attention est portée sur trois points :

· La base de données

· La description des fonctionnalités

· Les pages de l’application

Dans un projet, il est nécessaire de savoir ce que l’application permettra de faire. Pour cela il est important d’avoir un listing exhaustif des fonctionnalités ainsi que leur description.

Ex : voir que l’application contient une fonctionnalité de connexion implique que l’utilisateur a un compte donc qu’il existe une fonctionnalité d’inscription. Peut être que vous souhaitez que votre application soit dédiée uniquement à certains utilisateurs dans ce cas il est important que l’administrateur valide le compte créé avant que ce dernier soit accessible. Si l’administrateur doit valider un compte, il est peut-être nécessaire que ce dernier reçoive un mail automatique lui indiquant qu’un utilisateur a fait une demande de compte…

Pour le développeur, il est essentiel de savoir, pour chaque type d’utilisateur, ce qu’il doit être en capacité de faire à travers l’outil et ce que l’outil doit lui donner comme réponse. Avant de démarrer le développement, l’analyse d’une fonctionnalité passe par l’établissement de cas d’utilisation (use cases).

Un use case permet de décrire ce que va faire l’outil en réponse à une demande de l’utilisateur. Un use case concerne une fonctionnalité dans un scénario précis et peut se présenter de la manière suivante :

· Etant donné que (une situation de départ)

· Et (des précisions)

· Quand (une action)

· Et (des précisions)

· Et …

· Alors (une conséquence ou situation d’arrivée)

Ex : Fonctionnalité : Authentification

Scénario : Tentative d’authentification avec un compte valide

· Etant donné que je dispose d’un compte utilisateur

· Quand j’accède à la page d’authentification

· Et que je saisie mon identifiant dans le champ « Login »

· Et que je saisie mon mot de passe dans le champ « Password »

· Et que je clique sur le bouton « Connexion » du formulaire

· Alors je suis authentifié sur le site

· Et je suis redirigé vers la page d’accueil de mon compte

Dans l’exemple ci-dessus, un scénario est décrit. Cependant pour chaque fonctionnalité il est possible d’avoir plusieurs scénarii possibles. Dans l’exemple le scénario est une tentative d’authentification avec un compte valide mais il existe également un scénario de tentative de connexion avec un compte non valide où l’utilisateur rentre un mauvais login ou mot de passe. L’objectif est donc pour chaque fonctionnalité d’avoir l’ensemble des scenarii.

Chez IBC, nous utilisons la méthode de Test Driven Development (TDD). Cela signifie qu’en premier lieu, pour une fonctionnalité, nous codons des tests. Obtenir l’ensemble de ces scenarii permet à notre équipe de coder les tests correspondants qui nous assurent, tout au long du développement de l’application, de toujours avoir un fonctionnement respectant les spécificités de notre client et de ne jamais altérer l’existant (on parle également de test de non-régression).

Nous verrons dans un second article comment prévoir l’organisation de sa base de données afin de fluidifier le développement de votre application ou logiciel ! Stay tuned !

Biologistes, faut il avoir sa base de données en local ou chez un hébergeur ? Inconvénients et avantages

« Biologistes, faut il avoir sa base de données en local ou chez un hébergeur ? Inconvénients et avantages »

Aujourd’hui nous traiterons une question d’actualité ! En effet, vous avez sans doute entendu parler des récents incidents qui sont arrivés chez OVH Cloud. Le célèbre prestataire d’hébergement français a vu une partie de ses serveurs partir en fumée lors d’un incendie, détruisant l’un de ses centres de données à Strasbourg et en endommageant un deuxième. De nombreux sites et bases de données se sont retrouvés indisponibles suite aux incidents du 10 mars.

Touchant encore plus particulièrement les clients d’OVH n’ayant pas opté pour des options et/ou des solutions de back-up, l’incident a remis sur la table des questions autour de l’hébergement : Peut-on faire confiance à l’hébergement de nos données chez un hébergeur lorsque l’on voit que même l’une des plus grosses entreprises du secteur peut connaître des déconvenues ?

Chez IBC, nous avons l’habitude de travailler aussi bien à la mise en place de base de données stockés chez un hébergeur qu’en local et nous essaieront de vous donner les avantages et inconvénients de ses solutions.

!! Rassurez-vous, nous ne sommes pas alarmistes, que ce soit en ligne ou en local, il existe des solutions pour assurer la sécurité de vos données !

Stockage chez un hébergeur

Aucun texte alternatif pour cette image

La première raison d’opter pour un stockage chez un hébergeur est certainement la possibilité d’avoir accès à des solutions de partage de données sans avoir à investir dans du matériel et dans une maintenance trop importante. En passant par des prestataires tels que OVH, 1&1 ou encore Gandhi, vous ferez appel à une entreprise déjà équipée qui met à votre disposition ses serveurs pour l’hébergement de vos données.

Se présentant sous forme d’abonnement/location de serveurs, leurs offres vous permettent de sélectionner une solution adaptée et évolutive pour vos données. Proposant également différents services venant en complément de l’hébergement de vos données, les solutions qu’ils mettent en avant sont souvent avantageuses en termes de coût à court terme lorsqu’on fait la comparaison avec un hébergement en local. Vous bénéficiez de la maintenance et des mises à jour de sécurité effectuées par le fournisseur et comme les frais sont mutualisés entre les différents clients, l’hébergement chez un hébergeur est souvent plus rentable.

L’un des gros avantages du stockage de vos données chez un hébergeur est de vous permettre d’avoir facilement accès aux données que vous soyez sur votre lieu de travail ou en déplacement. Si vos projets de bases de données nécessitent du travail multi-équipe ou de permettre à des utilisateurs extérieurs à votre entreprise de se connecter, cela pourra être la solution la plus adaptée pour démarrer rapidement.

Le Cloud (hébergement en ligne de vos données, la formule proposée par la plupart des hébergeurs) se révèle être un atout pour les entreprises souhaitant concevoir un nouveau service sans avoir à investir dans des infrastructures lourdes comme cela était le cas auparavant. De plus, l’accès à ces services nécessite seulement une connexion internet.

Attention, si vous avez des données sensibles, tel que des données patients, il faudra choisir un hébergeur ayant reçu un agrément pour accueillir ce type de données, vous protégeant à la fois légalement et offrant des garanties supplémentaires contre les cyberattaques.

Un hébergement en ligne peut justement être la cible de cyberattaques ou d’incidents (bien que rarissime) comme ceux ayant eu lieu chez OVH. Il existe des moyens de se prémunir de ce genre de soucis en minimisant les pertes : choisissez toujours des solutions de Back-Up régulières. Cette option indispensable consiste à avoir des sauvegardes à des intervalles de temps précis (définissez quelle espace de temps représente une perte handicapante pour votre entreprise) sur un serveur indépendant de celui sur lequel est hébergé la base de données que vous exploitez. Soyez rassurés, tous les hébergeurs sérieux peuvent vous proposer des options de back-up simple à mettre en place.

Stockage en local 

Aucun texte alternatif pour cette image

L’avantage du local, c’est que vous avez le contrôle total de vos données. A vous de choisir et de vous faire accompagner par des professionnels pour construire votre base de données local et les infrastructures associées. Vous aurez une plus grande liberté sur les solutions de stockage à employer, mais il faudra aussi prendre en compte le fait que le stockage en local a un coût :

Comptez donc dans vos postes de dépenses une partie pour les serveurs, également des coûts d’infrastructure (il faudra prévoir un espace pour héberger vos propres données) et des coûts liés aux opérations de maintenance et de sécurité qu’il faudra peut-être internaliser. Il vous faudra une salle serveur réfrigérée et hautement technologique pour éviter les départs d’incendies.

Si vous souhaitez que vos données ne soient accessibles que sur le réseau de l’entreprise, c’est certainement la solution qu’il faudra adopter.

A vous de mettre en place les garanties de sécurité nécessaires à l’hébergement de vos bases de données en local. Vous travaillez peut-être au sein d’un laboratoire, d’une biotech ou d’une entreprise dans les secteurs de la santé, réfléchissez bien à la valeur de vos données et ce que peut représentez une perte ou un vol !

Comme pour le stockage en ligne, il faudra aussi penser à adopter des solutions de back up. Chez IBC, nous conseillons d’avoir au moins deux serveurs pour assurer la sécurité de vos données. Un serveur pour l’exploitation de vos données en direct, et un serveur pour effectuer les sauvegardes. Cette solution déjà sécuritaire vous permettra d’assurer la fiabilité de votre système de stockage. Il sera toujours possible de rajouter un troisième serveur pour une sécurité renforcée.

Avoir une meilleure maîtrise de ses données, c’est aussi pouvoir éviter plus facilement les attaques. Si vos données sont particulièrement sensibles, un hébergement sur votre propre réseau local coupé des accès extérieurs sera certainement un élément déterminant dans le choix du type d’hébergement à privilégier.

Petite remarque, un hébergement local pourra aussi vous permettre de partager en ligne vos données si vous le souhaitez. Si vous décidez que des utilisateurs en dehors de vos réseaux locaux aient accès à vos bases de données, la différence à faire par rapport au choix d’une solution de stockage chez un hébergeur se fera principalement au niveau de maîtrise que vous souhaitez avoir sur votre infrastructure data.

En résumé :

Avantages hébergement en ligne (cloud) :

Évolutivité des solutions

Prix

Facilité du partage de données

Solution Clé en Main (Maintenance, Mise à jour de sécurité)

Avantages hébergement local

Maîtrise de vos données

Choix de l’infrastructure

Maître de sa sécurité (possibilité de se couper des accès extérieurs)

Chaque solution a ses avantages et à vous d’opter pour celles qui correspond le mieux à votre projet. Définissez les éléments les plus importants dans votre stratégie de consultation et de partage de données et choisissez la solution la plus adaptée.