Votre présentation au COPIL s’est très bien passée. Néanmoins, malgré son intérêt, la proposition n° 1 que vous avez présentée a été jugée trop coûteuse : les membres du comité de pilotage ont donc opté pour la proposition n° 2 qui est moins chère, mais nécessite plus de développement…
Soit, vous acceptez cette décision ! Il est temps maintenant d’entrer dans le dur du sujet et de construire la solution “90 % web - 10 % Windows : 100 % fonctionnelle”. Il faut donc passer à la rédaction du cahier des charges technique.
La première étape est de concevoir l’architecture. Pour cela, vous devez formuler votre besoin auprès des architectes de l’entreprise. Ensuite, ce sont eux qui livreront le DAT, le “Dossier d’Architecture Technique”. Ce sera une pièce primordiale qui vous servira à la rédaction de votre cahier des charges technique.
Passons en revue les éléments à étudier. Pour chacun, spécifiez vos besoins par rapport à la solution que vous souhaitez développer.
Les besoins en performance
Combien de fois avez-vous abandonné un site web parce que le temps d’affichage était trop long à votre goût ?
En entreprise, c’est pareil ! Toujours plus vite !
Le ressenti des utilisateurs face à la performance de la solution que vous livrerez aura un impact direct sur la qualité de votre projet. Ce sera un critère majeur de succès ou d’échec. Il est donc important de connaître les attentes de vos utilisateurs.
Mesurez l’existant, et engagez-vous sur le futur. Une bonne pratique consiste à choisir un ou deux processus métiers et à les chronométrer.
Par exemple : vous pouvez mesurer qu’avec le logiciel “MonBonDevis”, il faut environ 20 minutes pour enregistrer un devis pour un nouveau client. Vous pouvez alors négocier un gain de 25 % avec votre nouvelle solution !
Pensez à amender le cahier des charges fonctionnel en ce sens.
Voici quelques critères de performance que vous pouvez prendre en compte et mesurer dans vos projets :
le temps de connexion à une application ;
le temps d’affichage d’une page ou d’un écran ;
le temps d’affichage d’un résultat de requête sur un filtre ;
le temps de téléchargement d’un fichier ;
le temps d’exécution d’un plan batch ;
etc.
Les besoins en disponibilité
L’aspect disponibilité est un moteur clé sur le coût global de votre projet.
Par exemple, si vos utilisateurs demandent qu’une application soit disponible 24 heures sur 24 et 7 jours sur 7, il faudra faire en sorte que, malgré cette contrainte forte, le service exploitation puisse assurer les opérations de maintenance nécessaires (la mise à jour des OS par des correctifs de sécurité, par exemple), ainsi que les sauvegardes régulières.
Vous devez donc vous assurer que les composants les plus critiques de votre architecture technique sont redondants, c’est-à-dire en doublon. L’un peut prendre le relai de l’autre en cas de panne ou de maintenance. C’est très important dans le cas d’une boutique en ligne, par exemple.
Toutes les applications ne sont pas critiques au point de nécessiter ce niveau de disponibilité. Aussi, vous devez comprendre correctement le besoin et challenger vos utilisateurs.
Par exemple, dans notre cas, les agences sont fermées le soir de 18:00 à 8:00 et le week-end du samedi 12:30 au lundi 8:00. Il suffit donc de prévoir les maintenances pendant les horaires de fermeture. De plus, si une panne survenait en semaine durant quelques heures, l’impact sur le chiffre d’affaires de l’entreprise serait minime comparé au coût que représenterait la redondance.
La gestion des risques de défaillance
Vous n’êtes jamais à l’abri de défaillances, d’interruptions de service de votre solution. Il s’agit d’anticiper et de se protéger des risques. Voici quelques stratégies et leurs impacts sur l’architecture.
RPO : Recovery Point Objective.
Quelle quantité de données l’entreprise peut-elle se permettre de perdre en cas de désastre (en nombre d’heures ou de jours) ?
Il faut mettre en place une stratégie de sauvegarde pour répondre au besoin de l’entreprise et respecter le RPO.
Par exemple : nous avons une sauvegarde tous les soirs à 22 heures, mais mon serveur plante à 19 heures, les données des dernières 21 heures sont donc perdues ! Si l’entreprise ne veut pas perdre plus de 2 heures de données, cette stratégie de sauvegarde n’est pas adaptée. Les architectes devront donc proposer une solution plus robuste.
RTO : Recovery Time Objective.
Combien de temps l’entreprise peut-elle supporter une interruption de service pour cette application ?
Organisation des équipes support : si le temps est court (2 heures par exemple), il faudra s’assurer que les équipes support sont organisées de jour comme de nuit, et la semaine comme le week-end.
Stratégie de sauvegarde : vous devrez également vous assurer que les équipes support seront capables de restaurer les sauvegardes en un temps record.
Redondance des composants : enfin, pour limiter le risque d’interruption, il faudra prévoir la redondance des composants les plus importants, c’est-à-dire doubler les serveurs de façon à ce que si l’un tombe en panne, l’autre prenne le relai.
DRP : Disaster Recovery Plan.
C’est un ensemble de procédures (techniques, organisationnelles, sécurité) qui permet à une entreprise de prévoir par anticipation les mécanismes pour reconstruire et remettre en route un système d’information en cas de sinistre important ou d’incident critique.
Stratégie de sauvegarde
Redondance des infrastructures (dans des data centers distincts)
Synchronisation des données
Pour se prémunir d’un désastre (tremblement de terre, attentat, etc.), il est fréquent que les applications les plus importantes du système d’information soient déployées sur deux sites physiques distincts et distants d’une centaine de kilomètres au moins.
Dans ce cas, il faudra prévoir :
d’inclure votre application dans ce dispositif ;
de prévoir les procédures de synchronisation des données entre les deux sites ;
de documenter les procédures qui permettront aux équipes techniques de basculer sur le deuxième site.
Les systèmes et middlewares
Nous l’avons vu dans la première partie, les systèmes d’exploitation et les middlewares seront choisis en fonction des besoins dictés par les applications qui supporteront les contraintes fonctionnelles, les règles d’architecture de l’entreprise et/ou vos éventuelles préconisations à la suite de votre benchmark.
L’enjeu à ce stade est de vous assurer que le dimensionnement de vos infrastructures est en phase avec les performances et les volumes attendus.
Voici quelques-unes des métriques importantes qui guideront votre dimensionnement :
Le nombre d’utilisateurs cibles
Le nombre d’utilisateurs concurrents
La taille de vos bases de données
La taille de vos filesystems
Le nombre de requêtes simultanées
Les processus et leur consommation en CPU et RAM
Etc.
La sécurité et les réseaux
Les aspects réseau et sécurité vont être déterminants pour la fiabilité et la performance de votre système. Ne les sous-estimez pas dans votre étude et là encore, pas d’inquiétude : vous n’êtes pas seul !
Chaque composant de votre architecture aura un rôle bien précis et sera soumis aux exigences que nous avons déjà évoquées (performance, disponibilité, etc.). Cela vous guidera dans vos choix. Je vous propose quelques axes de réflexion (il y en a d’autres) qui devraient vous aider à définir vos besoins techniques pour construire votre solution.
Concrètement, la bande passante sera directement liée à la nature de votre lien réseau (fibre, ADSL, SDSL pour internet, par exemple) et à votre matériel (cartes réseau, switchs). La latence, quant à elle, sera fonction de la distance géographique et des composants réseau/sécurité traversés (routeurs, firewalls, proxy, etc.).
La localisation
Composant par composant, identifiez la localisation la plus pertinente :
En salle machines sur les sites locaux ?
En data center ?
Dans le cloud ? Sur quelle zone géographique ?
Sur les PC utilisateurs ?
La zone réseau
Quelle est la zone réseau adaptée à votre besoin ?
Internet
Extranet
Intranet
Autre
Le plan d’adressage IP et alias DNS
Chaque nouveau composant de votre solution devra s’inscrire dans le plan d’adressage IP global de votre infrastructure et, idéalement, posséder un ou plusieurs alias DNS, en d’autres termes, le nom donné à chacun de vos serveurs sur le réseau.
Si la notion de plan d’adressage IP et DNS vous échappent, voici deux extraits du cours “Apprenez le fonctionnement des réseaux TCP/IP” qui vous permettront d’aller plus loin :
section “Un identifiant, l’IP” ;
chapitre “Le service DNS”.
Ces éléments seront définis par les architectes réseau sur la base des composants de votre solution (serveurs web, bases de données, etc.) et de leur localisation (agence, data center, etc.).
La matrice des flux
Identifiez l’intégralité des flux réseau, leur protocole, leur port et leur sens afin de permettre aux équipes sécurité d’ouvrir ses flux.
Le cryptage des flux et des données
L’échange de données sur les réseaux et notamment sur internet est du pain bénit pour les pirates du numérique. Vous devez donc vous en protéger. Une solution consiste à utiliser le protocole TLS pour vos applications web.
Comment savoir si votre application est protégée ?
Prenez le site de votre banque, par exemple. Vérifiez que :
l’URL commence par HTTPS ;
il y a un petit cadenas à gauche de l’URL.
Cela signifie que le site est protégé par un certificat.
Les services d’authentification
Identifiez la méthode d’authentification de vos utilisateurs sur l’application, mais également la méthode d’authentification de votre application à la base de données, par exemple.
Les services d’opérations
Le patching de vos composants : les éditeurs de systèmes d’exploitation et de middlewares proposent régulièrement des mises à jour afin de corriger des bugs et de combler les failles de sécurité régulièrement découvertes.
Les sauvegardes : nous en avons déjà parlé, il s’agit de définir la stratégie de sauvegarde adaptée à votre projet.
La supervision et la métrologie : ce sont les actions de surveillance et de mesure de la performance de vos infrastructures et applications.
L’ordonnancement : nous en avons parlé également, c’est l’automatisation de l’exécution de vos programmes. On parle aussi de “plan batch”.
Le rafraîchissement des environnements : c’est la capacité à mettre à jour un environnement grâce aux données d’un autre. Par exemple, pour tester une nouvelle version, on copiera sur l’environnement de test les données de la production.
En résumé
Comme je vous le disais au début de ce chapitre, rédiger le document d’architecture technique est une affaire d’architectes. Votre rôle, en tant que chef de projet SI, consiste à vous assurer que toutes les contraintes de votre projet ont été comprises et prises en compte.
Au-delà de la représentation graphique de l’architecture de votre projet, ce précieux document, le DAT, vous apportera de nombreuses informations pour la suite de votre projet.
Il va vous permettre notamment d’affiner :
votre planning ;
vos besoins en ressources ;
votre budget ;
et votre identification des risques.
Il vous permettra également de passer vos commandes de matériels et logiciels.
Enfin, le DAT vous sera utile pour apporter des précisions dans votre cahier des charges technique. Vous avez défini précisément vos besoins techniques pour tous les éléments que nous avons abordés ?
À présent, laissons un peu de temps aux architectes pour travailler ! Ensuite, passons à un élément central de votre solution : l’interface de l’application.
