D’une manière générale, le Système d’Information d’une entreprise se définie par l’ensemble des composantes, ou processus métier, permettant de traiter ses informations. L’une des principales est son Système Informatique, tant en termes matériel, réseau, qu’applicatif. Dans le cas présent, lorsque je parlerai du Système d’Information, il s’agira de désigner la partie Applicative du Système, que ce soit sous la forme d’un Logiciel, d’une Application ou d’un Site Web et ce, dans le but de récolter, traiter, stocker et servir l’information. A taille individuelle, un Système d’Information peut aussi être le smartphone qui est dans la poche de chacun...

Certains définissent le Cahier des Charges comme étant l’Expression des Besoins, ce qui est en partie vrai du fait qu’il la contienne, mais il ne contient pas que ça. C'est pourquoi il est important de traiter l’Expression des Besoins, qui sera formalisée dans le Cahier des Charges, comme un chapitre à part entière. L’Expression des Besoins est le départ de tous projets: c'est l’idée première qu'il convient d’approfondir et de détailler de manière brut, et qui sera affinée et formalisée dans le Cahier des Charges.

L’Expression des Besoins correspond à ce que le client, appelé maître d’ouvrage ou encore donneur d’ordres, attend du Système d’Information. C’est la représentation de ses besoins en termes fonctionnel/applicatif. L’Expression des Besoins ne comporte pas de solution finale mais la vision, en quelque sorte, de ce que le maître d’ouvrage attend. Cette expression peut être déjà réalisée par le maître d’ouvrage par écrit, mais elle peut aussi être une simple expression verbale qu’il conviendra de noter/formaliser dès les premiers entretiens, la phase d’initialisation. Dans tous les cas, qu’elle ait une préexistence ou qu’il faille la débuter de zéro, c’est une collaboration entre le maître d’ouvrage et le maître d’œuvre.

Dans le cas où le maître d’ouvrage compte, avec raison, sur le maître d’œuvre pour la réaliser en partenariat, sans réelle existence préalable, l’Expression des Besoins est un accompagnement du client par le prestataire de services pour lui permettre d’identifier et d’exprimer ses besoins et ses attentes. Le maître d’œuvre a tout autant un rôle de conseil que d’éveil: spécialisé dans son domaine, il saura identifier des choses que le maître d’ouvrage ne verra pas toujours immédiatement.

Selon la nature du projet, logiciel interne, application ou site Web, et du nombre d’acteurs en termes de parties prenantes (divers services ou employés amenés à devoir utiliser le produit final, les utilisateurs finaux), un certain nombre de réunions pourra être nécessaire, pour recueillir les besoins de façon plus détaillée. Dans ces réunions, chaque acteur sera amené à exprimer ses attentes le plus naturellement possible.

Le Cahier des Charges, ou CdC, reprend l’Expression des Besoins. L’Expression des Besoins donne naissance au Cahier des Charges. Le CdC est donc la description formelle, la formalisation, des besoins et attentes exprimés précédemment mis par écrit. Le CdC ne comporte en aucun cas la solution. En 2 fois 3 mots, c'est Le Quoi, non Le Comment. Le Cahier des Charges comprendra tout ce qui est en rapport avec le projet sur les aspects besoins et contraintes, tant sur le plan humain, technique, temporel que financier.

Le Cahier des Charges est généralement rédigé directement par le maître d’ouvrage: dans ce cas, il aura déjà lui-même formulé et rédigé l’expression de ses besoins. La phase suivante sera donc sa validation avec le maître d’œuvre.

Le Cahier des Charges peut aussi ne pas avoir été rédigé par le maître d’ouvrage: dans ce cas et dans la suite logique du déroulement du projet, ce sera un travail de communication collaborative entre les deux parties pour formaliser ce qu’attend le maître d’ouvrage et aura été préalablement exprimé de façon brut dans l’Expression des Besoins.

Lors de l’élaboration du Cahier des Charges, il s'agit de se concentrer sur ce qu’il faut faire et non sur comment il faut le faire. C’est à l’issue de la rédaction du Cahier des Charges que l’on déterminera si le projet est viable ou pas, notamment au travers des contraintes qui seront posées et étudiées, bien que l’Expression des Besoins indique déjà, dès le départ, si un projet est farfelu ou pas.

Les points exprimés dans l’Expression des Besoins sont revus et analysés selon l’ordre de priorité définie. Le Cahier des Charges exprimera ce que le maître d’ouvrage attend que le maître d’œuvre réalise pour lui pendant le projet. Le non-respect du cahier des charge entrainera des pénalités à la charge du maître d’œuvre.

Le Cahier des Charges est une pièce factuelle à laquelle se réfèrera le contrat pour définir ce qui est attendu et protège les deux parties de toute ambiguïté. Il assure au maître d’ouvrage que le produit final livré sera conforme à ce qui aura été convenu, et il assure au maître d’œuvre que le client ne lui réclamera pas quelque chose qui n’était pas initialement prévue.

Le maître d’ouvrage a la possibilité de modifier le Cahier des Charges en cours de route par un avenant accepté par le maître d’œuvre. Sans l’acceptation de cet avenant signé des deux parties, la modification n’a aucune valeur.

Qui dit Système d’Information dit expositions aux risques, risques en tous genres. Du risque de vol de données (une personne malveillante qui cherchera à s'introduire dans votre système pour accéder aux informations qu’il contient), au risque de mise en panne, le plantage du système (un employé qui voudra faire une blague ou ne pas travailler, ou une attaque externe...), le Système d’Information est succeptible d’être confronté, à un moment ou à un autre, aux risques. Il convient donc d’appréhender, au mieux possbile, ce que pourront être ces risques, les énumérer afin de faire et agir en conséquences. Il s'agira donc de dresser, méthodologiquement, la liste des risques, de les évaluer et de concevoir le Système d’Information en conséquence tout en prévoyant.

EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) est une méthode qui permet d’apprécier et de traiter les risques. EBIOS fournit tous les éléments nécessaires à la communication au sein de l’entreprise et vis-à-vis de ses partenaires, ainsi qu’à la validation du traitement des risques. EBIOS constitue de ce fait un outil complet et puissant de gestion des risques.

La sécurité de l’information a pour but de protéger le patrimoine informationnel de l’organisme. Celui-ci permet son bon fonctionnement et l’atteinte de ses objectifs.

L’Analyse Fonctionnelle consiste en l’étude des fonctionnalités qui formeront le produit final. Elle consiste à recenser l’ensemble des fonctionnalités du produit et à lister l’ensemble des éléments externes qui interagiront avec. Cela permettra de définir de façon plus précise l’usage du produit, son fonctionnement et son interaction avec les utilisateurs finaux. Cette définition se fera au moyen de fonctions détaillant les services rendus par le produit et les contraintes auxquelles il sera soumis. Le but de l’Analyse Fonctionnelle est de recenser, caractériser, ordonner, hiérarchiser et valoriser chaque fonction associée au produit.

L’Analyse Fonctionnelle doit être menée au début d’un projet. Elle évite le manque d’objectivité, l’aveuglement ou encore la mauvaise gestion des priorités. Dans un premier temps, l’Analyse Fonctionnelle est réalisée de manière générale et touche tous les acteurs du projet. Dans un deuxième temps, l’Analyse Fonctionnelle devient technique et aboutie aux solutions retenues.

Il s'agit donc d’identifier chaque fonctionnalité, en partant de la fonction principale du produit, et de s'étendre à toutes les fonctions qui en découlent, les fonctions adjacentes et sous adjacentes. Chaque fonction doit être catégorisée et nommée selon sa catégorie.

Il existe un certains nombre de méthodes permettant de réaliser l’Analyse Fonctionnelle, Bête à Corne, Pieuvre, APTE, SADT....

La Charte Graphique est avant tout une convention. Cette convention définira l’ensemble des règles graphiques et visuelles qui seront établies en rapport avec le produit et l’entité commanditaire. Cette convention représentera l’identité graphique, l’identité visuelle du projet. La Charte Graphique correspond à tout ce qui devra être suivie et respecté en tant que règles concernant les couleurs, les styles d’écriture, les formes graphiques primaires, le logo; d’une manière générale, de tout ce qui sera représentatif de l’identité graphique du produit et de l’entreprise. Les couleurs primaires sont initialement basées sur le logo de l’entreprise.

Il s'agit de garantir l’homogénéité et la cohérence de l’identité visuelle du projet. Il s'agit généralement de véhiculer l’image même de l’entité, entreprise, organisation, association ou personne, mais cela peut aussi être en rapport avec un produit ou un évênnement particulier, selon le type de site. Cela peut aussi être directement lié au produit numérique lui même tel que dans le cas d’une application, Web ou Android, ou d’un logiciel.

Le rôle de l’Interface Graphique, le rôle de la GUI, est de permettre à l’utilisateur de piloter et utiliser le Système d’Information à travers ses fonctions. C'est la GUI qui permettra à l’utilisateur d’accéder aux fonctionnalités du système, de les déclencher et d’effectuer des opérations, des traitements sans avoir à taper au clavier des lignes de commandes, comme c’était le cas il y a longtemps, ou comme c’est encore le cas pour les environnements en mode texte...

Définir l’Interface Graphique permettra de définir la position et la taille de chaque élément du Système d’Information, selon le type d’écran: les zones de texte contenant l’information destinée à l’utilisateur, les zones de saisie contenant l’information à transmettre au système, les boutons, les zones de choix, les zones de sélections... déclenchant des actions, marquant des choix, transmettant de l’information ou des commandes... Il s'agira donc de définir la position de chaque partie, zone, élément, de chaque vue pour un logiciel ou une application Android, de chaque page pour un site ou une application Web. Pour un site ou une application Web, le formulaire est l’élement d’interaction principal et prioritaire, avec le menu.

L’Expérience Utilisateur, ou encore l’UX pour User Experience en anglais, se rapporte à la qualité de l’expérience que vit l’utilisateur d’un Système d’Information pendant son utilisation. Cela passe par les émotions ressenties, l’anticipation et la facilité d’usage de l’interface. On peut donc parler du sentiment général que ressentira l’utilisateur pendant l’utilisation du produit. Pour mettre en place l’Expérience Utilisateur on parlera de la recherche de l’Expérience Utilisateur.

Le but de la recherche de l’UX est, par l’étude du comportement du système en rapport avec le comportement attendu de l’utilisateur, la recherche de la meilleure expérience d’utilisation. C’est déterminer ce que seront les meilleures interactions, au niveau applicatif, à renvoyer à l’utilisateur en fonction du contexte d’utilisation. C’est aussi et avant tout une question de fluidité d’affichage, d’effets et de retour dans le but de satisfaire l’utilisateur en termes d’utilisation, voir lui apporter un côté ludique si possible, sans que cela ne trouble son attention ou ne soit trop chargé.

Dans le cas d’un site Web, l’UX se rapporterra à la navigation au sein des pages, pendant l’utilisation de ses fonctionnalités afin de plaire à l’interrnaute et de l’amener à vouloir revenir. Amener l’utilisateur à revenir, pas obligatoirement pour acheter mais, par plaisir d’utilisation et pour la pertinence de l’information doivent être des facteurs de fidélisation des internautes. Dans le cas d’un site de vente en ligne, à produits et prix égaux avec la concurence, mise à part ce qui est de l’ordre de la sécurité, quelque chose doit faire que c’est vers ce site que l’utilisateur reviendra, et non pas vers un autre, et ce quelque chose, c’est l’Expérience Utilisateur. Un site qui n’offre pas une bonne Expérience Utilisateur ne sera pas susceptible de revoir les internautes l’ayant utilisé une première fois, à moins que l’information ou les produits que l’on y retrouve ne soient présents, ou disponibles, que sur ce site. Il y a aussi des cas tel qu’un bon produit connu présenté par un site pauvre en UX.

L’Expérience Utilisateur se voit associer esthétique, plaisir et facilité d’utilisation, toujours dans le but d’offrir quelque chose de plaisant.

Pour un site, il ne faut pas que l’interface soit complexe, mais suffisamment attirante et attrayante pour donner l’envie d’y rester, de l’utiliser et d’y revenir en véhiculant une notion de plaisir, la dopamine, tant dans le visuel que dans le réactif.

L’étude de l’Expérience Utilisateur porte sur les agissements des utilisateurs, afin de supprimer les éléments pouvant être un frein et déterminer les composantes à retenir pour créer le design. Le but est de répondre aux besoins utilisateur, en offrant une expérience de qualité, et d’atteindre les objectifs fixés par le maître d’ouvrage.

La modélisation est l’élaboration d’un modèle en vue de la représentation graphique du Système d’Information (site, application, logiciel) ou de l’une de ses parties: l’architecture du système, la partie fonctionnelle, la partie graphique, la partie données...

Il s'agit de se faire une représentation, sous forme de graphiques et de diagrammes, de ce qui aura été décidé durant les phases d’analyses et formalisés dans le Cahier des Charges et le dossier d’Analyse Fonctionnelle.

Le modèle Fonctionnel est la représentation architecturale du Système d’Information et permet de schématiser, au travers divers diagrammes et graphiques, son fonctionnement sur un point de vue technique au travers ses fonctionnalités, le but étant de réprésenter la solution fonctionnelle. Bien qu’il existe diverses méthodes d’analyse fonctionnelle, telle que SADT, ou encore SART pour le temps réel, la modélisation dite C4 Model a vue le jour entre 2006 et 2011 sans être au goûts de tous. Le système est d’abord décomposé en conteneurs et en composants pour une notation graphique simple. Chaque éléments est ensuite décomposés plus en détails, de plus en plus en profondeur et formalisés graphiquement en fonctions, interactions, acteurs... Le tout représenté dans un langage de modélisation graphique, généralement le langage UML, bien qu’il soit aussi possible d’utiliser Merise à ce niveau même si son rôle premier est lié aux données.

Le Modèle Graphique est la représentation de ce que sera l’Interface Graphique, la disposition des éléments qui formeront l’applicatif (site, application ou logiciel) en termes de présentation des composants graphiques du Système d’Information et des interactions avec l’utilisateur final pour les composants interactifs. Pour un site e-commerce, ce sera la représentation de chaque page, avec le menu principal, les zones de texte, les formulaires, les boutons, la dispositions des articles, la composition du panier, les différentes vues (Ordinateur, Tablette, Smartphone)... Le Modèle Graphique débouchera sur une maquette qui sera la représentation du produit final attendu.

Dans un Système d’Information, qu’il s'agisse d’un site web, d’un logiciel ou d’une application, l’information est représentée sous forme de données. Ces données sont stockées dans ce que l’on appelle une Base De Donnés. Le Modèle De Données est la représentation conceptuelle et logique de la Base De Données, comprenant les relations entre chaque donnée ainsi que les contraintes concernant leur stockage, leur accessibilité et leurs liens. Les données, la Base De Données et leur organisation, seront représentées selon plusieurs modèles, avec leur nom, leur type, leur relation, les cardinalité...

Le Développement du Système d’Information est la partie où tout ce qui aura été établie auparavant et formalisé dans le Cahier des Charges en termes de fonctionnalités, sera développé, avec l’Interface Graphique, selon ce qui aura été convenu et modélisé. - Développer signifie écrire dans des langages informatiques, un ou plusieurs langages de programmation avec, pour tout ce qui est en rapport avec le Web, un langage de balisage (HTML), un langage de mise en forme (CSS), un langage d’interaction (JavaScript), un langage serveur pour envoyer les pages au navigateur (PHP, C Sharp, Ruby...) et un langage d’interaction avec les données (SQL). -

Les opérations effectuées dans la Base De Données seront elle aussi écrites dans un langage informatique, un langage particulier, un langage de requêtes, la version SQL reconnue par le Système de Gestion de Base de Données utilisé, MySql/MariaDB, PostgreSQL, SQLServer...le SQL des SGBD ayant comme qui dirait un tronc commun en termes de mots clés/fonctions/instructions. Dans le cas de données pré-existantes de l’entreprise en rapport avec le produit, il s’agira de les insérer dans la Base De Données du produit, ou de mettre en lien le produit avec la BDD existante le cas échéant.

Le développement est le travail du, ou des Développeur(s), ou du, des, Concepteur(s) de Systèmes d’Information. Quand il y a plusieurs développeurs, ou des équipes de développeurs, chacun développe dans son domaine, design, interaction utilisateur, renvoie des pages du serveur vers le navigateur, et langage de requêtes pour ajouter/modifier/sélectionner/supprimer les données dans la Base De Donnée. Lorsqu’il n'y a qu’un développeur, tel que le Concepteur de Systèmes d’Information, on parlera de Développeur Full Stack, développeur à tous les niveaux, bien que tous les développeur Full Stack ne sont pas Concepteur de Système d'Information, sur le papier, dans la pratique tout est possible.

Au terme du développement, une fois tout développé et les tests de validation/d’acceptation effectués, la livraison du produit consiste, pour un logiciel, en l’intégration du Système d’Information au sein de l’entreprise, et, pour un site ou une application Web, à la mise en ligne et/ou l’ouverture en mode public. La prise en main est toute de même nécessaire dans le cas de logiciel, application privée, ou encore e-commerce pour la gestion du site en lui même sur ce qui concerne les ventes, les clients...