 La confection, ok, c'est intéressant. Renforce-moi des capacités parfaites. Confénalité, j'ai un ami de la vie du programme Thacker. Ok, on attend encore les autres participants. Complétude des données. Ah, il y a plusieurs facteurs qui entrent dans le jeu. C'est principe. Renforce-moi des capacités, c'est bon. Opérabilité. Ok. Évolution. Évolution, très bien. Ça réjoint la mise à jour. Ok, mise à jour, connexion, surcharge de travail. Là, fait très bien. Je pense que pour la plupart des inquiétudes et dans la section, je pense qu'on aura la plupart des réponses. On va aussi arrêter le serveur. Et je pense que nous ferons cela dans une section prochaine. Nous allons parler un peu plus de la maintenance du serveur et de sa configuration. Et durable. Ça rejoint toujours la maintenance, la flexibilité. Ça dépend du design que vous faites dans votre programme Thacker. Ok, la confidentialité, très bien. Nous allons discuter un peu dans cette section. Je pense que c'est bon. On a déjà la plupart des mots clés. Bien, la plupart des faits pour l'occupation, nous allons les aborder dans cette section. Et concernant le côté serveur. Et quant à la stabilité et la maintenance du serveur pour Prémadi, nous aurons ça dans une autre section la semaine prochaine. Eh bien, merci à tous. Je peux continuer la présentation. Bien, quand vous l'avez souligné tout à l'heure dans le Manti, il y a beaucoup des défis auxquels il faudrait faire face. Et les défis rencontrés au fil du temps pendant l'implementation du Thacker peuvent avoir plusieurs formes. Et commençons d'abord par les logiciels. D'accord? Il faut savoir mieux pour implémenter le DHF2. Il y a quelqu'un qui a ouvert son nouveau. Il faut savoir que lorsque vous implementez le DHF2, il y a plusieurs logiciels qui entrent dans le jeu pour son fonctionnement. Notamment pour la base et donner une utilisation du post-grid. Et nous, ce sont les templates pour le serveur web. Et bien sûr, l'application tourne sous Java. Donc tout fait logiciel. Et il faudrait veiller à l'heure maintenance. Nous allons venir en détail sur tout ça tout à l'heure. Toujours côté logiciel. Le DHF2 lui-même, que ce soit la version web 1.0.8, mais c'est ici qu'il s'est tenu en maintenance. Nous allons y revenir tout à l'heure plus en détail. Donc autre défis. Et c'est l'accumulation des données unitiles dans votre base de données. Donc là, nous allons parler des comptes utilisateurs. Nous allons parler des accès qu'on donne comme super utilisateur. Que ce soit pour un travail temporaire ou bien pour un travail permanent. Nous allons parler également des éléments de données qui peuvent accumuler dans le système. OK. Et troisième catégorie d'aspect. Nous avons les turnovers. Donc là, on parle de la rotation du personnel au sein de votre système. Donc un changement de personnel entraîne beaucoup de choses. Donc côté conception, il faudrait que les choses soient mobilisés pour que tout le monde s'y retrouve. Et la connaissance du système pour les nouveaux venus aussi très important. Et nous avons aussi le changement de convention. Notamment la définition des différents métal données. Donc nous allons y venir en détail tout à l'heure. Ici, nous listons juste les grandes lignes. OK. Donc sur la question du logiciel, comme des sites qu'on connaît souvent, c'est leur maintenance. Les mises à jour continuent. Donc lorsque, par exemple, vous avez un faveur qui tourne sur... Par exemple, Ubuntu 16. Et arriver quelques temps, disons quelques années, vous avez besoin de migrer vos systèmes de protection, mais Ubuntu 20. Qui est plus récent, qui est plus performant, qui est plus sécurisé. Donc ça, c'est l'un des défis auxquels c'est un peu fait face, lorsqu'ils ont l'air d'IHF de l'implémenter. Nous avons également les logiciels. Tom Keats, possiblement Java, qui connaissent des mises à jour réguliers. Donc pour d'autres aussi veiller à leur état des mises à jour. Nous avons le GHF2 lui-même, pour l'application GHF2. Que ce soit la version web mobile. Nous avons des mises à jour qui sont faites par les développeurs. Donc nous avons le coût des mises à jour annuels tous les six mois. Et nous avons aussi l'application de vos équipes qui connaissent souvent des mises à jour. Et ces mises à jour aussi, et dans le soin, la compatibilité avec les GHF2. Dans fait, deux facteurs font un point d'encontre. Donc la nouvelle version, et nous les avons tous fait six mois. Complètement la version GHF2. La mise en niveau de la version principale. Aussi être un facteur que vous devez prendre en compte. Et juste pour préciser, nous avons les versions et des mises à jour qui sont du genre le 2.34.3. Qui est une version de 1000 de base. Et nous avons aussi une version de base qui peut sortir, qui est la 2.104.4. Donc nous sommes toujours aussi la même version, GHF2.104. Mais nous avons les versions de base qui sont souvent mises à jour. En dehors de cette version de base, nous avons la version, la mise en niveau principale du GHF2, qu'on peut mal dire, qui peut passer de la version 2.104 à la version 2.35, 2.36. Donc pour ces différentes versions, il est important de pouvoir les mises à niveau. Et de temps en temps et périodiquement. Et ça, c'est la tâche qui est imprimée aux radiateurs-serveurs. Donc c'est aussi en fonction des réglementations. Donc côté logiciel essentiel. Et nous avons aussi la mise à niveau de l'infrastructure. D'accord? Donc lorsque vous faites une mise à jour de Louis-Ciel et il est important de faire un test de régression. Donc un test de régression, c'est quoi? C'est juste un test que vous faites pour voir si le changement apporté au Louis-Ciel a apporté des problèmes ou bien des erreurs dans le système. D'accord? Donc lorsque vous faites une mise à jour, par exemple, de la version pour se donner. GHF1 est de votre base de données, mais une autre version. Vous faites un petit test de régression pour voir si il n'y a pas des changements, si il n'y a pas des erreurs qui sont venus dans le système. D'accord? Maintenant, si vous faites une mise à niveau de la version du point OAR, j'en vous passez de la version de point 34.3 à la de point 34.4, comme ça. Et vous allez faire un test de régression des types moyens, donc un peu plus poussés pour essayer de voir si ces changements en deux versions de base n'a pas apporté quelques erreurs qui n'existent pas dans votre système. OK? Et parviennement, si vous faites une mise à niveau de la version principale du OAR, donc vous passez par exemple de la 2.33 à la 2.34, là vous aurez besoin de faire une test de régression complète dans les moins de détails pour s'assurer que tout va bien. Vous devez aussi avoir un plan de retour en arrière. Donc en faisant le test et en faisant la migration vers une version principale supérieure, vous pouvez avoir par exemple des erreurs pendant la migration et peut-être qu'on vous demande de faire un retour en arrière de revenir sur la version d'origine et qui sera utilisée en attendant de comprendre quel est le problème. Donc c'est pour ça qu'il est toujours important d'avoir un plan de retour en arrière. Vous ne pouvez pas faire une migration vers une version supérieure, planter le serveur et dire bon, le serveur est out et peut-être pendant une semaine jusqu'à ce qu'on corrige le problème. Donc quand c'est la arrière, vous revenez simplement en arrière pendant que vous cherchez à comprendre l'engruide. Et les versions d'engruide de DHS2 sont compatibles avec aussi une plage des versions de DHS2. Donc souvent, vous aurez besoin de faire une mise à jour de l'engruide lorsque vous faites une mise à jour côté serveur. Donc les mises à jour des applications aussi doivent être prises en compte. Vous n'êtes pas sans savoir que dans les DHS2 on installe les applications. Il est toujours important de les mettre à jour. Donc d'ici à prendre en compte lors de l'implémentation d'HF2 c'est l'accumulation des données unitiles. Donc dans ce contexte, nous n'avons pas par exemple les comptes utilisateurs. Vous avez entre par exemple des comptes zombies dans vos systèmes parfois, faits-t-il faits des comptes qui n'existent, mais qui ne sont pas utilisés, faits des comptes nés d'un atelier mais qui n'ont pas été supprimés ou retirés après l'atelier. Ça, ça arrive toujours. Ou bien faits utilisateurs qui vont vous dire ah je n'ai pas de comptes dans les systèmes et peut-être la administrateur ou les défaits de les chercher dans les systèmes il écrit simplement un nouveau compte. Or la personne avait déjà un compte qui existait. Donc on peut faire le tour avec une personne qui a jusqu'à 3 comptes dans le système. Ça y est ça, c'est pas normal. Nous avons aussi le type d'accès qu'on accorde pour compte utilisateur notamment l'accès comme super utilisateur. Vous pourrez avoir par exemple un atelier de paramétrage pour pouvoir faire le travail, vous donner des accesses par administrateur à des utilisateurs ou participants qui sont là. Et après la configuration souvent les utilisateurs peuvent tourner chez eux sans que vous n'ayez récorrégé leurs comptes. C'est-à-dire un chez eux toujours n'ayant le compte super utilisateur. Et on fait le tour dans les systèmes avec des dizaines et des dizaines normales, d'accord. Et l'accès administrateur c'est quelque chose qu'il faut gérer vraiment, vraiment avec précaution et avec soin. Et car bon, n'êtes pas sans faveur avec un constipé administrateur, il est très facile de détériurer simplement votre système pour l'égacheter en place. Donc, sur cette question d'accumulation des données unitiles, vous devez lancer des activités de routine ou faire l'analyse du système ou essayer de voir quelles font ces accumulations des données unitiles qui sont là et posséder à leur nettoyage. Donc, voici une capture d'écran ici qui vous montre un peu, qui vous montre l'application utilisateur. Au niveau de la base c'est Aléon. On a essayé de chercher un filtre et les utilisateurs qui ont été inactifs pendant deux mois. Donc, quand on a fait l'analyse, on se rend compte qu'il y a des utilisateurs par exemple qui sont connectés directement au système depuis 2013. Donc, pratiquement huit ans. Ok. Donc, ça c'est forcément un utilisateur qui n'est plus actif. Peut-être qu'il n'est même plus dans la santé. Peut-être qu'il y a les ailleurs travaillés ou bien qu'il n'a plus accès à rien de tout ça. Donc, il faut faire des défis. Donc, dans ce cas des figures, vous devez supprimer dans votre système. Ces comptes n'ont pas existé. Ok. Et cette activité, je pense que c'est le responsable de la sécurité du système de façon sanitaire qui peut être chargée de le faire. Donc, des temps en temps, périodiquement il peut faire ce check-in dans le système ou identifier ces comptes qui n'ont pas existé et à les supprimer tout simplement. Et il faut aussi prendre soin de limiter l'accès d'utilisateurs. Donc, si vous avez donné des accesses d'utilisateurs et au quartier de votre système d'information juste pour les besoins d'un paramétrage. Et après le paramétrage, il n'a pas besoin de garder ce compte d'utilisateurs. Il y a plein d'accès qui le permet de faire le travail dans la limiter du possible d'utilisateur. Donc, il faut vraiment vraiment limiter le nombre de personnes qui ont ce compte dans votre système. Moi, il y en a, mais votre système supporte. Donc, toujours dans le contexte d'accumulation des données unitiles, nous avons l'exemple des éléments de données des indicateurs qui ne sont pas utilisés. D'accord? Donc, ici par exemple, vous avez une capture d'écran de l'application Maintenance. Nous voyons la liste des entités d'accueil. Donc, dans cette fenêtre, nous voyons qu'on a voulu filtrer les attributes par NEM. Non? Et là, on constate, par exemple, que nous avons FirstNEM. Nous avons encore FirstNEM, mais écrit différemment. D'accord? Donc, techniquement, il doit s'agir de la même variable, mais qui a été créé deux fois. Donc ça, c'est un doublon. Et pendant le nettoyage, les utilisateurs doivent s'échanger de retirer du système. Plus il y a des variables unitiles dans notre système, plus vous compliquez la maintenance du système et plus vous augmentez les risques d'erreur lors de la collègue des dons. OK? Quelqu'un pourrait, par exemple, prier notre programme Thacker et l'assigner le FirstNEM pour un notre Thacker. C'est différent que vous aurez la même variable et qui est collectée, le FirstNEM, mais dans deux programmes Thacker différents. Or, je vous savais bien, il n'y a pas de méthode unique dans le système. OK? Donc, la nettoyage des metades données est nécessaire, qui ne fait pas l'administrateur. Il y a même l'ordre naturel. Et il se peut aussi, il peut l'ordre de nettoyage des données. Vous vous retrouvez dans l'obligation d'effectuer certaines importations de données. D'accord? Vous vous retrouvez dans la liste des données qui sont en même décalée par les dizaines. Et que vous l'avez créé deux fois et qui y a eu un peu différemment. Et si cette variable est saisie dans différents formuleurs et que vous devez supprimer la deuxième variable, vous êtes obligé d'importer les données de l'ancienne variable vers la nouvelle variable. Donc, ça fait un travail en plus. Et c'est souvent un fait qui mette le système, qui est en charge de chef, qui fait des travaux. Donc, d'où l'importance de s'assurer qu'il y ait des méthodes données dans votre système. Autre défi concernant le tournoi ou la rotation du personnel. Donc, vous avez votre système d'information sanitaire. Donc, les différents acteurs qui sont à l'intérieur, le gestionnaire des données, l'évadministrateur et il peut arriver que faire telle patte ou qu'il y ait un changement au niveau du intérêt sous humain. D'accord? Donc, c'est qui est important dans ce contexte que vous devez identifier en quoi ça peut impacter votre système et anticiper, déjà, la correction des saisures éventuelles. Donc, l'exemple que nous avons ici, donc, vous voyez dans la fenêtre à droite et un programme fracqueur et sur le suivi des grossesses. Et vous avez vu ce qu'il y a avec les clients rouges. Donc, dans cette variable, on a ses yeux 105 000 367 et ça doit être l'âge de la gestation. D'accord? Donc, vous imaginez que c'est un chiffre assez aberrant au lage de la gestation. Quand vous avez, par exemple, un équipe qui vient qui remplace quelqu'un qui avait pas ametté le fracqueur et qui voit ses yeux, la première question qui va se poser, c'est comment faire calculer. D'accord? Et si vous n'avez rien côté documentation qui lui permet au moins de voir comment vous avez pas ametté les règles de programme pour faire ce genre de calcul, vous ne pouvez pas corriger ce genre d'erreur. D'accord? Donc, vous voyez dans cette fenêtre au milieu où nous avons filtré les règles de programme et quand on tape pour gestation donc, c'est pour essayer d'identifier les différents règles de programme qui ont dans le calcul cette variable, on se retrouve avec plusieurs méthodes données, plusieurs règles de programme qui ont une même connotation. C'est difficile de se retrouver. Donc, dans ce cas, ce que la personne doit faire, c'est de fouiller les règles de validation pour lesquelles fait effectivement le calcul de cette hache de gestation avant de le corriger. Donc, d'où la nécessité de documenter vos méthodes données? Vous devez avoir un référentiel des méthodes données. Quelqu'un a mis son micro. Vous devez avoir un référentiel des méthodes données qui est clairement et comment certains calculs sont faits pour que, lorsque il y a un changement de personnel, il y a d'autres actions du personnel, que celui qui arrive puisse comprendre comment vous avez possibilité pour faire certains calculs et ainsi pouvoir effectuer une maintenance facile et rapide du système. Donc, toujours côté votations du personnel et il y a le facteur qu'on efface du système qui entre en jeu. D'accord? Vous devez documenter les systèmes. Vous êtes tenu de mettre en place toutes les documentations nécessaires pour permettre à peut-être votre emplacement ou à quelqu'un d'autre de se retrouver et de comprendre comment fonctionnent les systèmes. D'accord? Donc, vous devez documenter les travaux de personnalisation de vos différents programmes. Et vous devez documenter les différentes enseignements qui vaient tirer lorsque vous utilisez un indicateur comme au niveau central. Et vous devez documenter votre SOP. Donc, les profiliers généraux d'utilisation, déflatation de votre système. Vous devez tous les documenter. Et mettre ça à la disponibilité. Quelqu'un a lui mis son micro. Merci. Et toujours au niveau. Je ne puisse pas vous répondre vraiment ? Quelqu'un a lui mis son micro. OK. Donc, toujours qu'on fait mal la rotation du personnel. Nous avons le problème d'échangement de convention qui peut se vénir. C'est notre bouchis. Donc, c'est quoi l'échangement de convention? Nous parlons là de la nomenclature ou de la façon d'une nommée ou différentes métadonnées. OK. Donc, ici à droite, vous voyez la fenêtre d'utilisateur. En capture d'écran. Donc, ce qu'on constate là-bas, par exemple, c'est que nous voyons que pour une même variable, plusieurs choses ont été saisies. C'est-à-dire le nord des différents groupes d'utilisateurs ne suit pas un schéma identique. Les schémas changent de groupes en groupes. Donc, c'est là du format à l'arrivée. Sous-jouement de nouveaux gestionnaires, ou des nouveaux utilisateurs de système. Et lorsqu'il arrive, on peut lui demander de créer un peu d'utilisateurs pour la city. Les recommandations ont été agressées à toutes les dépenses. Et un micro qui est allumé. Vous pouvez le fermer. Merci. Donc, vous pouvez avoir, par exemple, un nouveau administrateur qui arrive, et on lui demande de donner créant un groupe d'utilisateurs qui va assaisir un formulaire donné, un formulaire A. Donc, quand cet administrateur s'occupe de l'utilisation des utilisateurs et regarde les groupes d'utilisateurs, il peut ne pas se retrouver. D'accord? Selon la nomenclature telle que la nommée fait prédécesseur, il peut regarder les noms des différents groupes, mais ne pas identifier qui est adapté au groupe spécifiquement et qu'on lui a demandé de créer. D'accord? Donc, ce qui va se passer dans ce cas des figures, c'est que notre administrateur va créer un nouveau groupe. Et de la manière dont il peut l'identifier plus facilement. D'accord? Donc, ceci arrive parce qu'on n'a pas une norme, une convention qui est définie pour notre système et qui va lui permettre de suivre une certaine logique, lorsqu'il crée des metades données ou bien lorsqu'il nomme les metades données dans le système. D'accord? Donc, autre facteur, défis, c'est de créer des données. D'accord? D'accumulation des données. Et bon, lorsque, par exemple, vous créez votre raccord pour une première fois et bien sûr, elle sera quasiment vide puisqu'il n'y a pas beaucoup de données saisies, mais on a offert à mes yeux que les jours, les semaines, les mois ou les années passent, vous avez de plus en plus de données dans votre base des données. Des milliers, des centaines de milliers, pour pouvoir les calculer et générer les indicateurs, ça demande beaucoup de ressources et côté serveur. Donc, dans ce cas-ci, bon, vous ne pouvez pas empêcher l'augmentation des données dans le système, ça c'est sûr, mais à moins vous pouvez essayer de les gérer au mieux. Donc, exemple, comment vous ne pouvez pas, exemple, réduire votre favel de votre serveur, faire de jouer sur l'assignation des favoris ou bien des dashboards utilisateurs. Et par exemple, c'est un un petit peu administrateur qui est là. Et s'il lui, par exemple, n'a pas besoin d'être différent d'analyse votre dashboard, puisqu'il est juste là pour la administration, il n'a pas soin analyser ses dashboards. Et c'est un peu unitile de lui donner des dashboards très lourds qui font l'agrégation de tous les données du pays, d'accord? Donc, vu qu'il espère admis, il aura forcément accès au niveau et à chaque le plus élevé au niveau pays. Donc lui donner des dashboards très lourds c'est déjà augmenter la charge de calcul côté serveur, parce qu'à chaque fois qu'il nous sort des dashboards, le serveur doit émuler calculer tous les favels et tous les indicateurs et réafficher sur les favoris. Donc ça, c'est juste un simple exemple de comment vous pouvez limiter la charge tout simplement. Et vu que chaque limitien aura son dashboard qui sera attaché à sa formation sanitaire et la quantité de données est assez limitée, donc le dashboard s'écharge rapidement et sans problème. Par contre, pour tous ceux qui sont au niveau pays, il faut limiter le nombre de personnes le plus possible qui ont un dashboard complet très lourd, qui sont très beaux mains en ressources. OK? Dans le cadre de l'accumulation des données, vous avez ici le plus l'application d'attaqueur. Nous avons affiché les enrollements pour le programme et je pense que Clément, petit souci avec son sa connexion, je crois qu'il va nous rejoindre d'ici peu, mais je m'en vais peut-être rapidement continuer. Je ne sais pas si vous voyez mon écran. Oui. D'accord. Donc il était sur ce point comme il le disait au début c'est facile d'avoir une base plus ou moins vite où il n'y a pas beaucoup de données, mais au fil du temps, les données commencent pas à grandir ou être beaucoup plus important dans le système. Et rapidement, on voit que les doubles saisis peuvent arriver, ce qui a l'audit plus ou moins la base de données. Avec la saisie tracker, il faut quand même bien former les opérateurs de saisie afin qu'ils puissent savoir que pour pouvoir par exemple enseigner les informations des autres étapes de son traitement, il faut quand même rechercher la personne par la peine de récréer doublement cette personne dans la base. Donc c'est fait là, il arrive souvent et c'est ce qui fait que dans notre base de données, nous avons des données en double dans le système. J'ai été déconnexé. Et il faut ce travail de maintenant. Bon peut-être que je vais te laisser continuer. Ah ok. Et désolé bien. Donc comment nous les disait, donc là nous avons par exemple la liste des enrôlements pour le programme, celui des enfants qui est souvent très grand donc vous pouvez avoir par exemple des dizaines de milliers d'enfants enrôlés. Généralement quand la personne qui est chargée de faire saisie du tracker et quand elle vient de cette page elle ne fouille pas la liste qui est là pour trouver peut-être l'enfant qui est un micro qui est allumé donc généralement ce qui serait plus simple au lieu de charger cette liste exhaustive des enrôlements c'est de demander simplement à l'utilisateur que dès qu'il arrive fait de page d'aller simplement à la recherche ici et de chercher et l'enfant pour lequel il va saisir les informations d'accord. Donc déjà ça permet de réduire la charge de charger tous les enrôlements ces dizaines de milliers d'enrôlements qui sont là. Il n'y a pas. Donc les défis et nous les avons énumérés tout à l'heure donc maintenant nous allons voir pour chacune des catégories des défis et les différents solutions qu'on peut utiliser ok. Donc concernant les logiciels obsolètes vous devez faire une mise à jour du logiciel de manière outinière programmé, une mise à jour régulière et selon les versions ou par période et c'est bien et vous devez prendre en compte la mise à jour des versions de base tout comme la mise à jour des versions principales du DHS2. C'est qui est très important et je rappelle en même temps ici que les versions du DHS2 qui bénéficient du support de la communauté sont toujours les 3 dernières versions donc veillez ne pas être en dehors de 3 dernières versions de DHS2 qui seront sorties. Et sur la question de l'accubilation des données unitiles vous devez bien sûr effectuer le nettoyage de la base et vous devez supprimer et désactiver les utilisateurs qui n'ont rien à faire dans le système et vous devez effectuer soit une analyse intégrité pour voir dans la base des données que vous devez nettoyer et supprimer les doublons et supprimer les attributs des doublons etc etc et concernant le turnover la rotation personnelle et vous devez mettre à disposition des outils, des documents qui permettent à tous les acteurs de comprendre comment fonctionne le système et pour mieux les dépanner pour mieux faire la maintenance de la disposition indicionnaire des données, indicionnaire des metades données donc un référentiel où chaque utilisateur, lorsqu'il cherche les détails d'une metade donnée peut le retrouver dans ses dictionnaires bien sûr mettre en place un des sorties pour gérer les faits qui va dicter la maintenance du système quand il faut mettre à jour un tracker comment nous allons procéder quand il faut ajouter certains indicateurs et qui doit le faire ok donc vous ferez ensuite le sujet bien sûr pour voir si les différents critères sont pris en compte et si le système fonctionne très bien il n'y a pas j'essaie pas si on continue on va prendre quelques questions avant d'attaquer l'épopétie de maintenance et les gestions des changements on ne voit que deux questions ici ok donc la première question de Kofi Martial qui demande si la suppression des données de paramétrage dans le DHS2 se supprime réellement dans la base de données Postgrease ou le cache couvre cet aspect est-ce que ça reste un cache ou est-ce que c'est réellement supprimé dans la base de données il n'y a pas de cas de chubu ça va dépendre de ce que vous supprimez dans la base de données souvent on met un affaire du état de suppression sur le métro c'est que c'est supprimé dans la base de données donc si ça n'est pas utilisé dans le système pour les calculer tout ça il y a une autre question il y a une autre question mais bon j'arrive à ajouter un un un un un un un un un pour ajouter un mot là-dessus il peut arriver aussi dans l'un de ces cas que vous faites une suppression définitive mais que vous voyez toujours les données dans la patrie analyse c'est possible dans ce cas il faudrait faire une configuration server bon on appelle le cache engineer mais les administrateurs serveurs savent généralement comment faire ça donc c'est un travail que vous pouvez faire un grand job, c'est-à-dire en tâche planifiée lorsque vous faites les supprochets et que ça reste toujours dans la ITX. Merci beaucoup. Effectivement, il y a des données qui reste toujours en tâche et il faut souvent vider ce tâche-là et l'admissateur aussi la possibilité d'aller dans le maintenance où vous voyez une partie qui vous permet de supprimer la sorte qui vit dans le système. Donc, si vous le cocher ou le lancer, ces données-là aussi vont partir, mais bon, il y a aussi ce que nous laissons sur le serveur qui permet de vider rapidement ce cache du serveur là. Il y a aussi une question de Hanta qui parle de la maintenance. Si cette maintenance dont on parle est aussi valable et donnée agrégée, oui effectivement cette maintenance est valable et donnée agrégée. Ce qui se passe aussi souvent c'est dans les procédures qui permettent de concevoir la base. Il y a certaines règles que nous adoptons avec toutes les parties prénantes, avec les membres de l'équipe technique, les membres de l'équipe de développement, je veux dire. Et si je prends le cas de 0,4 ans par exemple, ils peuvent l'adopter dans le système. Donc on crée une option 0,4 ans dans le système et on la joute aux autres des agrégations pour pouvoir présenter le formulaire. Maintenant aussi quelqu'un vient dans le système pour lui, c'est inférieur à 5 ans. Donc s'il va dans la partie option et qui tape 5 et qui ne le voit pas, il va se dire que ça n'a pas été créé dans le système. Ce sont souvent moments qui vont aussi le payer. Ça, ça dit la même chose. Donc pour pouvoir corriger ces gens de dysfonctionnement dans le système, on essaie de voir si ces options ne peuvent pas de donner. Donc on fait quelques maintenance ici et là pour pouvoir contourner ces aspects. Il y a aussi une question liée à comment identifier les éléments de données offland dans le système. Je pense que il y a aussi maintenant une partie qui permet de pouvoir lancer, d'avoir une vue d'ensemble sur l'analytique. Donc il y a aussi ces éléments de données qui sont qui seront listés. On va dire les éléments de données qui ne sont pas utilisés sur un formulaire. Donc il va sortir cette liste là et vous allez pouvoir avoir ces éléments de données, ces indicateurs, des indicateurs qui ont la même formule. Aussi ces gens d'information vont sortir et il faut prendre cette liste-là et ensemble avec l'administrateur des systèmes, vous aurez un temps pour pouvoir corriger cette liste que vous avez. Bon, c'est ce que nous appelons le data clinic. Je pense qu'il y a quelques questions qui tombent ici et là. Si on peut continuer, on va revenir à la fin de la deuxième section de cette présentation. Donc Clément, on peut avancer? OK. D'accord. Bien. Donc nous allons revenir aux questions dans le slack tout à l'heure. Nous allons finaliser la présentation. Et le processus de développement et processus de maintenance de votre programme. OK. Donc pour concevoir votre programme, bien sûr, vous allez commencer par les développements. Donc pas développement en tant à l'analyse des différents outils et la documentation des variables, l'identification des stats, la création des éléments d'identity tracker et la création des attributs, des programmes pour magie, des règles de programmes, etc. D'accord. Donc lorsque vous finissez de développer votre programme, faites un premier test. Donc vous allez faire un test pour voir si l'assaisie dans le programme fonctionne très bien et s'il y a des erreurs, bien sûr, vous allez les corriger et ensuite quand tout va bien, vous passez à la mise à l'échelle pour le lancement de l'application. D'accord. Donc une fois que l'application est mise à l'échelle et nous entrons dans la phase de maintenance. Aignant espace. Voilà. Nous entrons dans la phase de maintenance. Donc pendant que l'application est utilisée, il est possible qu'on revienne à vous, que vous aidez autour. On vous demande, par exemple, à cet élément de données, il n'est pas suffit à être dans ces stats dont on est déplacé dans l'autre stack. Nous devons ajouter telle variable. Nous devons supprimer ceci, et ceci, et ceci là. Donc vous avez une mini-book qui reprend, où vous allez encore remodifier le tracker, faire le développement, refaire un petit test et le déployer de nouveau. D'accord. Même après cette première boucle de rejus de votre programme, vous pouvez encore avoir des retours qui vont encore vous demander de faire encore quelques modifications dans le développement, mais vous allez faire les tests et vous l'aurez encore fait un lancement. D'accord. Et il n'y a pas. Donc tous ces processus, il n'y a pas encore. Donc tous ces processus encadrés ici en rouge, c'est ce que nous pouvons nommer les processus de gestion des changements. Oui, il n'y a pas. C'est le processus de gestion des changements. D'accord. Donc qu'est-ce que nous avons à faire pour ces processus? Souvent il s'agit des nouvelles fonctionnalités. Donc nous ajoutons des champs, nous ajoutons des stats et ceci, et ceci là. Et nous modifions le calcul des certains indicateurs. Nous les voyons certains favoris ou mettre à jour les dashes tableaux du bord. Et fait changement aussi pour tester sur la correction des certains erreurs ou des mises à jour. D'accord. Genre, et comment l'on l'a vu pour la COVID-19? Et les directives relatives à la surveillance du COVID ont beaucoup évolué depuis l'évolution de la COVID-19. Et donc au fur et à mesure des changements, il y a eu fortement des changements aussi dans le programme tracker. Donc c'est aussi un exemple de correction du bug et des mises à jour que vous aurez dans votre processus de gestion des changements. D'accord. Et oui, il n'y a pas. Donc, lorsque vous avez fait genre de changement et dans un programme tracker qui est déjà en utilisation et vous avez plusieurs contraintes. Donc, notamment le efficage, c'est-à-dire la formation et des utilisateurs. D'accord. Et lorsque vous faites des modifications majeures dans le programme tracker, il est important de faire encore une fois la formation des étudiantes pour qu'ils puissent se retrouver, pour qu'ils se retrouvent et pour qu'ils comprennent comment votre programme fonctionne. Et bien sûr, c'est là un peu également la mise à jour du votre matériel de formation. Si vous aviez fait des documents, des vidéos, il faudrait les revoir et les actualiser. D'accord. Et plus important encore, je disais même que c'est le plus beau du travail, c'est l'esprit de migration des données. D'accord. Et vous avez déjà un programme tracker qui est là. Il fonctionne. Les gens ont saisi des dizaines et milliers de centaines de données à l'intérieur. Et lorsque vous faites une mise à jour de ce programme, que vous déplacez une variable ou bien que vous actualisez une variable, vous êtes obligé de faire un script qui va déplacer les données, par exemple, d'un stade à un autre, et ou bien ajuster certains attributs d'un arrondissement. D'accord. Donc ça fait un gros travail qui doit être fait. Donc vous mettez en place le script pour pouvoir aller de la deuxième version vers la nouvelle version de votre programme tracker. Et guiappo. Bon, le mot du jour, c'est tracker and read. Donc c'est un vision de la noté, c'est le mot du jour. Je pense que vous pourrez le noter quelque part et vous allez remplir la liste de présences. Merci. Merci Agno, guiappo. Et bien, OK. Configuration des tests. Donc ici, nous avons un exemple de comment on peut configurer les tests d'un programme tracker que vous développez. Donc ceci a été fait par Ispoganda, je crois, fait au Malawi. Et donc le processus, c'est le suivant. Et lorsqu'ils ont développé le programme tracker, ils ont élaboré un plan pour les tester. Donc dans ce plan, ils incluent les différentes phases, les différents scénarios possibles pour tester le programme tracker. Et pour tester ce programme, ils ont fait dans différents environnements, d'accord? Et interne comme externe, c'est-à-dire au niveau des développeurs comme au niveau des utilisateurs. Et surtout, ce qui est important, c'est qu'ils ont documenté clairement les résultats du test. Donc pendant le test, lorsqu'il y a un comportement inapprofondi quelque part, c'est noté quelque part, lorsqu'il est calculé bien fait, c'est noté, etc. Donc pour ce fait, ils ont utilisé ces fichiers qui sont là, c'est juste un modèle où ils ont essayé d'identifier chaque variable, le comportement qu'il est censé avoir et les erreurs qu'ils ont trouvées et est-ce qu'ils s'est corrigé, est-ce que c'est pas corrigé, d'accord? Donc avec ces documents, ils arrivent à faire les tests de leur programme tracker, sans rien oublier, bien sûr, et tout cela est documenté, d'accord? Et quand cette documentation est faite, c'est qu'il y a corrigable et corrigé. Et à partir de ces documents, et guiappo, à partir de ces documents, il devient possible d'élaborer un guide et des tests pouvant toutes les fonctionnalités. Donc, un guide sera élaboré et qui va permettre aux stylataires du choix de tester l'application. Donc le guide sera détaillé. Et j'en commence à louver au système. Quels sont les prêts des guides pour faire les éros au système? Ici, en exemple, vous avez à voir un ordinateur connecté, à voir un navigateur et à voir un compte au système, d'accord? Donc ça, c'est juste un petit exemple dans le guide des tests. Et le guide des tests comporte là aussi des différents captures d'écran qui vous montrent les résultats attendus, selon ce que vous rentrez dans un champ d'un autre, d'accord? Donc, ce guide des tests va vous permettre de dérouler l'application, de les tester, de ne les laisser passer, bien sûr, de quand tout en compte et de voir réellement si l'application est parfaitement fonctionnelle. Donc associé à ce guide des tests, nous avons les résultats des tests et comment ça a été résolu, qui peut accompagner à ça. Celui-ci, celui que vous avez dans le point inférieur droit, où nous avons la variable. Et on dit, par exemple, comme erreur, si cette variable n'est pas achetée dans le formulaire, ce qu'il faut faire, c'est développer, par exemple, ici un formulaire de personnalité, etc., etc. Donc avec le guide des tests qui couvrent toutes les tests possibles d'application et un document qui affiche les résultats et les résultats du test et comment résoudre les erreurs éventuelles, vous avez quelque chose qui vous permet de valider le programme FACRE que vous implementez. Diapo. Donc, développer le FACRE, ça c'est bon, c'est fait. Maintenant, c'est qui important, c'est de tester les équipements avec lesquels les utilisateurs pour pouvoir capturer les données, d'accord ? Donc, dans ce contexte, il est important de tester différents équipements. Qu'il s'agit des Android, par exemple, vous pouvez tester plusieurs Macs Android. Nous avons ici, par exemple, la liste et d'être des Android testés dans le cadre de l'assistance au Malawi, par l'ISPSA ou GANDA. Donc, ils ont testé les Android, tel que vous voyez le nouveau Samsung, différentes versions et différents tailles d'écran, d'accord ? Et il est toujours important de faire fait test avec les différents résolutions pour voir comment se comportent l'application, ces différentes résolutions de portable. Il est aussi très important de faire le test dans des environnements différents. Ne pas faire contenter de faire le test dans le bureau, par exemple, de l'équipe qui fait le développement, mais il faut aussi faire le test au niveau utilisateur. C'est-à-dire aller sur le terrain, voire le contexte réel dans lequel sont les utilisateurs, faire le test en utilisant le réquivement, le réseau dont ils disposent au niveau de la formation sanitaire, si possible, faire le test avec différents opérateurs réseaux, d'accord ? Donc, tout ce test permet un peu d'évaluer et comment on peut faire la mise à la question de l'application et peut-être identifier les lacunes à combler pour que ce déploiement soit facile, d'accord ? Et vous, vous allez également faire le test avec les PC ou les Chromebooks et en testant comment ça se fait avec la saisi au clavier et à la souris. Et est-ce que le Bluetooth marche très bien ? Et est-ce que l'autonomie de la machine termine a aussi détenu longtemps ? Est-ce qu'il y a des sous-alimentations, tout ça, là ? Donc, tout ce test faut nécessaire pour déjà anticiper la mise à l'échelle de votre raccord. Diapo. En processus des déploiements de votre raccord, bien sûr, pour déployer votre programme, vous devez former les utilisateurs et mettre à jour le matériel lorsque vous avez des changements majeurs dans le programme packer. Je vais vous démodifier les tables ou bien ajouter certaines statutes et palates. Il faudrait vraiment faire une mise à jour du matériel, de formation. Mais l'offre fait juste une petite mise à jour très mineure. Exemple, juste on a changé légèrement le libellé d'une variable. Et je ne commence pas fortement de refaire tous les matériels de formation. D'accord ? Bien sûr, il faut être communiqué toujours avec les futurs télépathiques sur les changements et les déploiements. Ok. Et établie aussi un plan de déploiement des versions qui est bien clair. D'accord ? Donc, si nous avons migré notre DHS2, si pour exemple, nous sommes à la dépointe 33 et que nous nous n'allons à la dépointe 35, nous devons avoir un plan clair qui stépule comment ce processus va se réaliser, comment va se passer la migration. Et donc, dans ce contexte, il n'y a pas. Donc, voici par exemple un petit schéma qui peut vous élitrer le processus de lancement de votre programme tracker. Donc, il y a deux critères très importants qu'il ne faut pas en rendre compte lorsqu'on voulait et lancer le processus de migration de votre programme. Et il faut faut un plan de gestion des versions. D'accord ? Donc, le plan de gestion de la version, il n'y a pas le plan. Il faut un plan de déploiement de la version de base. Et je vais d'avoir listé les grands items à venir dans les détails. Donc, le plan de déploiement de la version de base, c'est ce qui va définir votre processus de migration, de migration de DHS2 et de notre. Comme je l'ai dit tout à l'heure, vous voulez passer de la dépointe 33 à la dépointe 35. Qu'il faut qu'il fasse ? À maintenant, plus de ce plan, il faut toujours un plan de repositionnement de base. J'ai un plan de retour en arrière. Si vous faites immigration et que ça ne passe pas mal. Au lieu que les systèmes froid off, vous pouvez faire un retour en arrière en attendant de voir ce qui s'est passé lors de la migration, en attendant de corriger le problème. D'accord ? Donc, pour chacun de ces catégories de plans, vous avez un petit exemple de quoi peut ressembler votre processus de lancement, votre plan de lancement. C'est ça qui a une numérité de 1 et un pour moi ça, par 1 à 4, il faut bien 5. Donc, pour le plan de déploiement de la version de base, par exemple, vous pouvez avoir un plan un petit peu contenu, par exemple, en premier, fermer la production pour tous les utilisateurs chinois, c'est-à-dire vous bloquer l'accès à la production à tous les utilisateurs. Après, c'est là où vous pouvez passer à la sous-regard de la base, de données. Ensuite, vous allez sur les détails de mise à niveau, telle que ce qui peut laisser la page officielle du DHS2, comment migrer de migration à une autre. Donc, ensuite, vous appliquez les patchs, vous appliquez les patchs, etc. Ensuite, vous faites la vérification des changements, d'accord ? Donc, vous regardez si la mise à jour fonctionne bien, est-ce qu'il n'y a pas des erreurs qui sont apparues, est-ce qu'il n'y a pas un changement dans le comportement de cette construction, etc. Et lorsque tout va bien maintenant, vous pouvez ouvrir l'environnement de production aux utilisateurs que vous avez précédemment bloqué. Donc, vous redettez le serveur en activité. Donc, ça, c'est le plan de déploiement de la version de base, DHS2. Maintenant, lorsqu'il s'agit d'un plan de repositionnement ou le fermer à charrières, donc là, vous allez simplement restaurer la base des données que vous avez précédemment, c'est le backup. Et vous resterez, bien sûr, l'ancienne version de DHS2. Donc, exemple, j'ai voulu faire la migration vers la déploiement de 35% échoué. Et je ne rêve pas la base des données de la version de 33% précédente. Et je vais déploie le war de la version de 33% précédente. Et je vérifie si tout va bien. Et je revois maintenant l'accès au serveur aux utilisateurs. OK. Et ça, c'est bien. Et donc, c'est qui est important? Et il y a plusieurs facteurs qui entrent dans la modification de la base des données lorsque vous faites les migrations. Vous en, par exemple, vous fly away l'esprit des migrations et qui modifie la taille des valeurs de champs dans votre base des données pour qui supporte un plus grand plage. Et vous avez aussi l'esprit des migrations qui vont jouer sur le déplacement des données d'utilisation et d'autres besoins. D'accord? Donc, ici, en exemple, lorsque vous avez besoin de déplacer certaines données, par exemple, bon, les positionnels sont données d'une ancienne version d'une base à une nouvelle base et que c'est scripté chou, souvent, c'est scripté pour plus de faits. Si le chou, vous aurez forcément besoin de revenir en arrière, d'où la nécessité du premier de retour en arrière que vous en parlez précédemment. OK. Donc, ici, par exemple, nous avons un schéma qui élite un peu le processus de mise à niveau et d'un programme, par exemple, un programme factory dans un système. Donc, vous avez à droite la base de production qui est là. Donc, ce qui se passe, c'est que, au fin de mise à jour du programme, on va d'abord récupérer la base actuelle et les méthodes données, même si possible, du programme actuel sur la base de production. On l'importe dans le serveur des développements qui est là, en premier. Donc, d'assez des vrais des développements, les développeurs pourront travailler sur la mise à jour du programme factory et effectuer également les petits tests de ces idées pour voir si le programme est bon. D'accord ? Donc, lorsque le développement est fini et que le programme est mis à jour, les méthodes données de ce programme seront importées dans le serveur des tests, qui est au milieu, et container les données de production. D'accord ? Donc, si ce serveur test, les plusieurs utilisateurs pourront effectuer les tests, donc, c'est faire plus que les devs, on pourrait trouver plusieurs utilisateurs sur les tests, ou voici le nouveau programme Tacker qui fonctionne très bien. Et si les données ont été repositionnées comme il faut, et grâce au skip et tout ça là, et quand tout est bon, on peut simplement répliquer la base test, la production, et réouvrir maintenant à tous les utilisateurs, tout simplement. Donc, ça fait un exemple positif de Moodie, qui peut être utilisé pour mettre à jour vos différents programmes et tout ça. Diapo, Diapo toujours, Diapo. Diapo, c'est le bon processus. OK, les recommandations. Donc, et on récapitule rapidement, faut régulièrement nettoyer les anciennes méthodes données, donc vérifier si il y a des méthodes données qui flottent, des méthodes données zombie, entre-grips, vous voulez supprimer, qui servent à rien. Et maintenir le système à jour, donc les logiciels, veiller à la mise à jour du Java, du Post-C, du Tomkit. Et selon ce qu'il est supporté par les DHS-2. Et mettre à jour les versions de base du DHS-2. Donc, vous avez une version de DHS-2 qui est là, l'autre qui est un patch qui sort, et une version de base qui est là, qui est plus sécurisée. Vous nous faites la mise à jour, c'est très important pour la sécurité. Et envisager aussi les mises à jour de la version principale du DHS-2. Je n'ai pas fait de la version du contractor à la version 33. Donc, il faut avoir fait dans votre plan de maintenir votre système, et définir peut-être par quelques listées, vous allez le faire. Et garder les forgards que la base est donnée, ça, c'est très, très, très vital. Et nous allons beaucoup en parler dans la session sur les serveurs. Et les bases de données vous faites les backups. Et vous gardez les préférences et les backups sur nos serveurs, pas sur les mêmes serveurs, juste pour plus de sécurité. Et vous pouvez tester et faire regard sur une machine future, vous assurez qu'ils fonctionnent très bien. D'accord ? Et documenter la conception de votre système, ça fait très important. L'offre vous fait de la multiplication de votre documenté, et avoir des additionnaires des méta-données, des références qui permettent à tout utilisateur, qu'il soit nouveau ou ancien à les systèmes, de pouvoir vite comprendre comment votre système est configuré, comment fonctionnent les différents calculs, etc., etc. D'accord ? Et lorsque vous voulez faire des modifications sur des programmes faciles ou des méta-données, évitez de le faire sur la production différemment et directement, il est toujours important de faire face aux références des tests et des développements. D'accord ? Et il faut toujours vérifier et tester toutes les modifications et toutes les mises à jour qui offert sur un programme avant de le mettre dans la production, et que tout le monde commence à l'utiliser. Il faut toujours faire cette vérification. Et il est toujours intéressant de diviser les instances nécessaires. D'accord ? Je vais m'expliquer que vous avez l'instance agrégée qui est là, qui contient les données agrégées qui sont saisies, et par exemple, vous l'implémentez maintenant en facteur pour le VIH. D'accord ? Et il est plus intéressant d'avoir par exemple votre VIH, votre grand VIH dans une autre instance préférée, pas sur la même instance que l'agrégée. D'accord ? Et ceci a dit au fait que les restrictions, les restrictions sécuriteures pour ces types de données sont très différentes. D'accord ? Côté VIH, nous exigeons plus de confidentialité côté données, plus de sécurité, parce qu'il y a un peu d'incédés de données très sensibles, et donc il est toujours intéressant de le mettre sur notre instance, sur lequel nous donnons la lassitude, peut-être de mettre une sécurité plus accrue, ou bien plus récent à l'utilisation de cette instance-là. Il n'y a pas. Donc, en résumé, vous avez fait une liste de contrôle, que vous devez prendre en compte lorsque vous implementez ou maintenez votre facteur. Donc côté maintenance, il faut un SOP pour les utilisateurs et les admins, et les processifs de mise en service et au service de l'osystème de la tèque Claire Magy chez nous. Dans quelqu'un, vous mettez votre système à mainténance, dans quelqu'un, vous le mettez en service. D'accord ? Vous devez documenter tout ce qu'il y a à votre système, les référentiels des données, les différentes variables, tout, tout. Et vous devez surtout aussi faire le monitorage. Ah, le monitorage, on n'en a pas beaucoup parlé, qui est très important. Donc le monitorage vous permet de monitorer les activités sur le serveur, et l'avantage du monitorage, c'est que ça va vous permettre d'anticiper un problème avant qu'il n'arrive. D'accord ? Et il y a plusieurs outils pour faire le monitorage, et nous avons, par exemple, le Glowroot, qui est très intéressant, qui permet de voir l'air et kit le plus, il est plus lancé sur votre serveur, et le temps de réponse, etc, etc. Donc l'intérêt de monitoring fait d'effacer que le système utilise les ressources comme il faut, et d'anticiper, peut-être, des ventes qui peuvent arriver, peut-être faute de ressources ou bien de manques de mémoire sur le système. Et de plein de mises à niveau, bien sûr, pour avoir plein de mises à niveau clair, qui dit quand est-ce que vous devez mettre à jour votre gestion du DHF2, il y a quelques idées citées. Et la gestion du changement, donc pour chaque changement, lorsque les gens changent, il faut prendre en compte un plan de formation pour le modifier le design de votre DHF2. Et il faut avoir un plan de test, comment vous testez vos applications, comment vous allez le lancer, et le déployer dans votre part de production. Et bien sûr, et assurer que tous les utilisateurs puissent l'utiliser, et puissent être recyclés à son utilisation. Je vais dire pas. Donc quand vous prenez en compte tous ces facteurs, quand vous prenez en compte tous ces et la liste de ces plans et que vous les implementez proprement, donc vous avez cette jolie maison qui est là, qui est votre problème, qui fonctionne très bien, et qui va, disons, être efficace, efficient, et pendant une très longue période. Et merci beaucoup. Je pense qu'on peut retourner aux questions, peut-être. Je vais ouvrir le Slack, peut-être. Donc côté Slack, j'ai vu une question, est-ce que, comment identifier les éléments de données au filet? Souvent dans le DHF2, c'est plus facile d'utiliser l'analyse d'intégrité de la base qui peut vous sortir. Et les éléments de données, par exemple, qui ne sont pas utilisés ou bien qu'ils sont faux au filet. Donc cette analyse vous permet d'identifier beaucoup de variables et d'utiliser votre système. Et quelle différence est-il? Quelle est la différence entre administrateur et utilisateur? Question posée par Omic. Et l'administrateur, par exemple, peut avoir accès à la filet pour maintenance ou entrer les méthodes données et peut aussi gérer l'utilisateur. Par contre, l'utilisateur et filet, par exemple, au niveau de la formation sanitaire, offre-nous son DHF2. Il a juste accès par exemple aux applications saisies des données et analyse. C'est tout. Il peut rien faire d'autre. Dans le cas du traqueur, il aura accès au programme traqueur tout simplement. Mais pas aux autres applications qui peuvent modifier les méthodes données du système. C'est juste à la différence. Et l'administrateur DHF2 a une différence sur l'administrateur côté serveur. Donc celui qui a accès aux serveurs pour promotion et qui génère le backup et tout ça. Et question de fouiller. Est-ce que la suppression des données du paramétrage n'aura pas de conséquence sur le plan de retour en cas d'erreur des mises à jour? Et justement, c'est à nous à déjà répondre à la question. C'est pour ça qu'on demande de faire un backup avant de faire ces gens de mises à jour du système. D'accord? Si vous avez un backup avant de faire les modifications, lorsque tout ça s'est passé mal, tout ce que vous avez à faire c'est de revenir sur l'ancien backup que vous avez fait tout simplement. Est-ce qu'il y a de questions? Par l'un de la facturation du système à la longue, est-ce qu'il y a des dispositions prévues de prévenir cela? Autrement, est-ce que les anciennes données de plusieurs défais ni d'offre être forcément gardées ou peuvent être supprimées? Bon, je l'ai dit tout à l'heure et votre base va aller juste en croissant. Vous ne pouvez pas éviter qu'il y a de plus en plus de données dans le système. Et il est là pour ça, de toute façon. Donc, ce que vous pouvez faire déjà pour éviter la facturation du système, c'est déjà de faire le monitoring. Donc, si vous faites le monitoring et que vous constatez que votre serveur est à manque de mémoire ou à manquer les disques durs, vous pouvez envisager et simplement une ennapoudrie de votre serveur, c'est-à-dire avoir un serveur plus puissant, ou augmenter la rame, ou augmenter le professeur, ou augmenter les disques durs pour corriger le problème, tout simplement. Mais techniquement, l'importance de ces voies de système d'information c'est de garder tout vos données au même endroit. Donc, les anciennes données quelquefois à leur âge, il est important que vous les ayez. L'essentiel, c'est de nous assurer que vous avez mis tout à nouveau pour que votre système ait le ressource nécessaire pour fonctionner comme il faut. C'est tout. Bon, Anu a déjà répondu. Peut-on se promener qu'il faudra qu'il dise pour des données passées? Anu a répondu, c'est non bien sûr. Et est-ce qu'il y a un impact innovatif sur la suppression de ces utilisateurs? Et il n'y a pas. Lémon, je voulais juste ajouter aussi. Oui. Pas à part la suppression des FOSA. Ça, ça dépend. C'est pas parce que la FOSA a fermé, parce que j'ai vu des commentaires après. C'est pas parce que la FOSA a fermé qu'il faut forcément supprimer cette formation sanitaire de l'instance. Mais si c'est une formation sanitaire en double dans le système, bon, il faut penser à comment convoyer les données de la formation sanitaire B vers la formation sanitaire A. Ça, c'est la première des choses à faire. Quand on le fait maintenant, il faut penser à la suppression de cette formation sanitaire. Mais le problème, c'est que quand on utilise le DHS2, il y a des liens qui se crée entre les utilisateurs, la formation sanitaire, les données, les out-pôtes ainsi de suite. Donc pour supprimer une FOSA, par exemple, qui a été utilisé sur un tableau de bord, il va falloir supprimer ce lien entre la FOSA et ses out-pôtes. Quand je parle de out-pôtes, c'est le tableau quasi dynamique, le visualiseur, la carte. Il va falloir faire toute cette suppression avant de pouvoir supprimer la FOSA dans l'instance. Ce qui n'est pas chose facile directement via l'interface. Mais si c'est une formation sanitaire que vous avez créé tout de suite, et que vous voulez supprimer, ça, ça passe rapidement parce qu'il n'y a pas de lien créé. Maintenant, pour les anciennes FOSA, nous avons en fait un script qui permet de supprimer ces gens de formation sanitaire. Mais ça doit être exécuté directement sur le serveur. Mais néanmoins, on peut s'amuser à partager ces gens de script avec vous. Donc c'est ce que j'aimerais en fait préciser parce que j'ai eu de commentaires. Je ne saurais dire tout ça dans cela que c'est pour ça que j'ai voulu quand même les supprimer ici. Ok, merci beaucoup Agnan. Je continue avec les questions. Supprimer la suppression d'information sanitaire avec les données peut-elle influencer sur l'ensemble des données d'entités concernées? Bon, l'ensemble des données il faut toujours comprendre que c'est indépendant. Donc les formuleurs de quand vous laissez supprimer vous ne touchez rien à vos données. Donc si vous supprimez la formation sanitaire et que vous avez supprimé aussi les données il y a cette formation sanitaire tout simplement. Mais l'ensemble des données s'il est assigné à eux il est toujours là. Je crois qu'il n'appelait pas des questions sans répandu. Sauf si Jérémie. Agnan, est-ce qu'il y a une question ? Oui, il y a quelques questions. Il y a même l'intervention dans commentaire ici Arsène qui voulait voir pardon, Marthès, on n'a pas, ça n'a capturé pas les idées donc je ne vois pas très bien ce que tu as envoyé. Si tu peux envoyer de nouveau. Je pense que Jérémie a même répondu d'accord. Mais il y a Arsène qui demandait si on pouvait rapidement montrer quel genre de maintenance il faut faire. Je ne sais pas si il voit mon écran. Celui du DHS2. Je ne sais pas si mon écran. Donc il y a un administrateur de données ici et quand vous cliquez là-dessus vous avez d'atteint integrity. En fait c'est ici quand vous le lancez il va essayer de checker tout ce qu'il y a d'un normal dans votre système partant des des options qui ont le même code des éléments de données qui ont le même nom des indicateurs qui ont la même formule des éléments de données qui ne sont pas utilisés sur un formulaire il va vous sortir toute une liste des choses à corriger dans votre système. Donc quand vous pouvez le lancer ça prend quelques temps pour finir donc je vais pas le lancer ici. Peut-être je n'ai pas grand-chose ici dans le système donc ça peut passer rapidement. Mais au-delà de ça vous voyez donc là où il y a le rouge rouge ça veut dire que ce sont des éléments de données à checker. Donc ces éléments de données ne font pas partie d'aucun groupe. D'accord? Donc il va falloir quand même les checker. Il y a aussi les unités d'organisation offre-là. Son groupe là où c'est vert ça veut dire que c'est bon. Donc vous devez par moments checker cette liste-là pour pouvoir corriger rapidement certaines choses dans votre système. Au-delà de ça nous avons maintenance ici. Ce qui est différent de maintenance ou administration que nous avons ici. Donc ici vous avez la possibilité de supprimer tout ça comme donné. Comme nous supprimons certaines données ça reste dans la base de données. Et c'est ce qu'on appelle les soft-dilits. Donc il porte une autre mention dans la base de données. Et pour pouvoir épurer complètement ces données on peut cliquer sur ces volets-là. Donc on vous clique sur tout ce qu'il y a comme soft-dilits. C'est en ce moment que ça parle définitivement de la base de données. D'accord? Donc quand je le conche je peux le lancer. Donc en ce moment qui va supprimer toutes ces données dans le système. Maintenant il peut arriver il peut arriver que dans votre système vous avez supprimé une personne surtout pour le trac vous avez supprimé une personne mais quand vous lancer l'analyse ça reste toujours. Donc vous pouvez aussi vider le cache ici. D'accord? Mais il y a aussi une manipulation qui est là pour en fait vider l'étable analytique parce que c'est qui alimente en fait les tableaux de bord et les autres outils d'analyse. Maintenant quand vous essayez de supprimer en fait la table analytique sachez que vous vider tout ce qu'il y a comme table des données les tableaux de bord seront en fait vides. Maintenant le problème ici c'est que si vous vider en fait cette table analytique et que vous lancer de nouveau la compilation des données et que cela est chaud ça veut dire que les données qui seront les tableaux de bord seront toujours vides. D'accord? Donc il faut faire très attention quand vous essayez de vider l'étable analytique c'est pas ce qu'on fait tout le temps. D'accord? Mais il faut lancer une fois l'analytique pour savoir peut-être carrément ici il faut prendre peut-être une année pour lancer. D'accord? Donc pour savoir si en fait les données vont aller jusqu'au bout. Donc quand vous le lancez vous prenez une année par exemple vous le lancez il va prendre son temps pour compiler toutes les données. C'est ce que nous voyons sur les tableaux de bord. Donc quand nous ici nous vidons cela ça permet d'enlever toutes les données qui sont restées soit peu dans un cache ou ainsi de suite sur le serveur. D'accord? Donc mais il faut faire attention il faut lancer une fois l'analytique et ça va aller jusqu'au bout. Donc ça va prendre quelques minutes pour marquer le point cocher-cocher jusqu'à la fin. Parce que si jamais ça ne va pas au bout vous n'aurez toujours pas de données dans votre DHS. D'accord? Donc ici vous voyez que tout a marché correctement. Du coup je peux m'amuser à vider toutes les tables analytiques et à recommencer. D'accord? Ça ne supprime pas les données en fait mais ça supprime juste les données temporaires dans la base de données qui nous permettent de voir peut-être certaines données pas trimestres par mois par semaine ainsi de suite ou pas à année. Mais les données que les gens s'existent dans le système restent toujours et ce n'est pas ici qu'on pourra supprimer ces données-là. Maintenant autre chose quand nous faisons en fait la migration d'une instance à une autre peut-être la version 2.28 à la 2.29 ou une autre version on nous demande en fait de supprimer les SQL. Donc ce sont des choses qu'il faut faire on peut ici supprimer les SQL ou directement l'administrateur du système nous dit va le faire directement sur le serveur mais tous sous ces points là sont décrits en fait dans le upgrade note ici. Donc ici quand vous cliquez dessus vous allez avoir qu'il faut ici par exemple la version dans cette version demande d'installer le flyway et d'exécuter en fait ce script-là et de changer aussi la version du post-grad de passer à la version 9.6 ainsi de suite. Il y a ces directives qui sont ici donc c'est ce qu'il faut appliquer quand vous essayez de faire une maintenance sur le serveur ainsi de suite. Donc il y a par moments quand vous saisissez dans un champ peut-être pour les données agrégées quand vous saisissez dans une combinaison ou une combinaison ça met en rouge mais à côté ça passe donc il faut venir faire cette maintenance au niveau des combinaisons de catégories pour qu'ils puissent checker la nouvelle combinaison de catégories peut-être aller aussi ensemble de données pour voir quelle est la combinaison que notre formulaire utilise finalement. Donc il y a de ces petites choses là qu'il faut faire aussi dans la maintenance pour que votre système marche correctement. Ici c'est juste pour régénérer tout ça comme table ressources qui alimente en fait ce que nous utilisons au niveau du visualiseur ainsi de suite. Donc voilà ce qu'il faut savoir ici on peut plus ou moins pour ceux qui n'utilisent pas de tracker demander au DHS de ne pas voir se voler parce que au début je l'ai lancé tout à l'heure c'est passé mais quand nous prenons un système d'un pays c'est beaucoup plus de données ça peut prendre des heures et des heures donc il faut faire attention ne surtout pas prendre all mais prenez une année pour que cela aille rapidement donc c'est ces gens de maintenance qu'il faut faire mais il y a aussi le volet à pays que certaines personnes sont en maîtrise réellement et ça nous permet de voir un peu plus en détail ce qu'il y a ce qui ne va pas ainsi de suite ainsi de suite donc je crois qu'on a dépassé largement le temps on peut continuer dans cela merci beaucoup à Clément pour cette bruyante présentation nous allons continuer dans cela je me permets de d'annoncer une pause 15 minutes donc à tout à l'heure à 11h45 merci c'est là merci tout à l'heure