Ce document a pour objectif de permettre à l'équipe Histologe (ou tout repreneur) de prendre la partie technique de la plateforme en main.
Histologe est un système d'information qui permet de détecter et accélérer la prise en charge du mal-logement.
Cette plateforme fournit
- un guichet unique de signalement à des usagers en situation de mal-logement,
- un back-office pour permettre aux agents de communiquer plus facilement et résoudre plus rapidement les signalements qu'ils reçoivent.
Trois types de personnes y ont accès :
- les administrateurs techniques et métier du système
- les agents et responsables de territoire qui accèdent au back-office et gèrent les signalements
- les usagers qui déposent un signalement et peuvent ensuite suivre l'évolution de son traitement
Le système d'information est de type monolythique et hébergé par le prestataire Scalingo. La mise en route et l'arrête des systèmes se fait grâce à l'interface de gestion fournie par Scalingo.
Trois conteneurs séparés existent et peuvent être arrêtés ou redémarrés indépendamment. L'utilisation de Redis permet d'augmenter ou réduire le nombre de serveur qui tournent en parallèle, au besoin, en cas d'évolution de l'activité.
- Le tableau de bord fourni par Scalingo donne un accès à l'état des accès au serveur et à la base de données
- Updown.io nous alerte en cas de baisse de performance soudaine
- Sentry nous alerte en cas d'erreur d'exécution de code
- Des tableaux de bord internes créés via Metabase permettent de visualiser les cas d'échec d'interconnexion avec d'autres services
Le logiciel updown.io envoie des notifications automatiques, en fonction du temps de réponse et de la métrique qu'ils appellent Apdex.
Voir le document de Procédure de gestion des incidents de sécurité
Chaque jour :
- la personne en charge du support de la plateforme vérifie la présence d'erreurs nouvelles ou récurrentes sur Sentry (via les alertes e-mail ou le tableau de bord)
Chaque semaine :
- les tableaux de bord de suivi (Metabase, Scalingo, Dashlord) sont consultés régulièrement.
- la personne en charge du support fait aussi une sauvegarde des bases de données et des fichiers de la plateforme sur un disque dur externe déconnecté le reste du temps
Nous suivons les évolutions majeures des frameworks utilisés pour rester sur des versions éprouvées et maintenues.
Le registre des équipements et applicatifs peut se trouver sur le cloud de l'équipe.
Si un correctif est mis en place, une branche Git est créée, suivie d'une Pull Request relue par au moins un développeur tiers.
Un tunnel d'intégration continue fait des vérifications de qualité de code (SonarCloud) et de tests automatisés. Il est exécuté à chaque commit sur une PR et à chaque fusion de branche. Le déploiement n'est fait qu'une fois ces vérifications validées.
Le déploiement sur le serveur de production n'est fait que lors de la fusion entre une branche de développement et la branche main.
- GitHub, via Dependabot, crée automatiquement des PR quand un composant a des vulnérabilités connues.
- Les versions de PHP, MySQL et Symfony sont mises à jour de manière régulière, en fonction des sorties stables
Voir le document de Procédure de gestion des incidents de sécurité
Les mots de passe comportent au moins 12 caractères, dont 1 minuscule, 1 majuscule, 1 signe spécial et 1 chiffre.
Un compte administrateur a accès à l'ensemble des fonctionnalités du site.
Chaque personne de l'équipe a son propre compte administrateur. L'authentification se fait en double facteur : mot de passe et code envoyé par e-mail.
En cas de départ, l'accès est annulé et le compte est conservé mais archivé.
Un compte d'agent a accès au back-office de la plateforme. Trois rôles existent donnant accès à un éventail différent de fonctionnalités : agent, administrateur partenaire, administrateur territoire.
En cas de compte non-utilisé pendant plus de 2 ans, le compte est anonymisé et archivé.
Voir le document de Procédure de gestion des incidents de sécurité