Notre étoile du nord c’est « de quelle informatique aurons-nous besoin en 2050 si on veut rester dans les préconisations de l’accord de Paris (COP21) ? »
Nous pensons que le mail en fait partie, et nous pensons également que la constructions de communs numériques avec l’opensource est une bonne manière de le faire.
Notre projet à moyen terme :
proposer un service de mail, de gestion de calendrier (CalDAV) et de contacts (CardDAV) (c’est fait)
ouvrir le service également à des noms de domaines externes aux notres (c’est en prod, ce sera ouvert sous peu)
pour chaque service (site d’accueil et app de gestion de compte) entrer dans les critères :
fournir une/des images docker pour que des assos/comptes puissent auto-heberger les mêmes services
ouvrir (ils le sont pour la plupart) les dépôts de code source cf Iroco · GitHub
passer sur codeberg car nous ne faisons plus confiance à Microsoft / github.
Nos services sont hébergés à Roubaix chez OVH pour l’instant. Nous avons sélectionné cet hébergeur car il est en France avec une attention sur l’impact environnemental, et une certaine transparence sur leur hébergement (ils font partie par exemple de l’association Boavizta) à laquelle nous avons souscrit également). Si nous devions en changer nous conserverions ces mêmes critères.
C’est notre deuxième candidature. Depuis la première voici les changements :
migration de Eolas vers OVH comme hébergeur pour des raisons de praticité et d’autonomie
passage de mailjet vers une solution auto-hébergée basée sur keila (blocant pour la première candidature).
Hello @bam ! Merci pour votre 2e candidature et votre tenacité
Je viens tester l’accessibilité (a11y) de votre site web. Le site est plutôt accessible, bravo !
Chouette que l’accessibilité vous importe ! J’ai vu que vous aviez eu un audit d’accessibilité, mais comme j’ai du mal à le parcourir et qu’il a 2 ans, je ne l’ai pas utilisé comme base, donc c’est un regard « frais ». Il n’est pas non plus basé sur le RGAA complet, je fais avec mon expérience informelle.
Bon, j’ai quand même relevé quelques problèmes, notamment une mauvaise utilisation des niveaux de titres. Je décris les problèmes après, mais pour des informations génériques sur ce sujet, la documentation de MDN sur les niveaux de titres est complète et paraphrase ce que j’en dis ici.
Retours d'accessibilité
Sur plusieurs pages, il y a plusieurs titres de niveau 1, ce qui n’est pas une structure correcte de document HTML. Le premier titre pourrait rester au niveau h1 et les suivants pourraient être des titres de niveau h2. Par contre ce n’est pas un problème si le h1 et les h2 suivants ont le même style visuel
Il y a un titre de niveau 1 dans le header, juste après le logo, qui ne contient aucun texte. Je pense qu’il ne sert à rien et qu’il pourrait être supprimé ?
Sur plusieurs pages, juste avant le bouton « Ouvrir un compte », il y a à nouveau un lien vers la page d’accueil qui me semble inutile. Peut-être laisser le logo, mais supprimer le lien ? Vous pouvez voir ce lien en appuyant plusieurs fois sur la touche « tab », jusqu’à arriver à cet endroit dans la page.
Sur la page « À propos », partie « Feuille de route », il y a un titre de niveau 2, puis juste après un titre de niveau 3. Je pense que le titre de niveau 3 devrait plutôt être mis en gras / en gros avec du style, mais que ce soit un <p> ou un <strong>, plutôt qu’un titre.
Dans la FAQ, les catégories des questions sont représentées par des h2 dans la table de contenu (TOC) en haut, mais pas dans le corps de la page. Pour que la structure soit correctement comprises par un lecteur d’écran, ces h2 devraient être dans le corps de la page, avant les questions/réponses. Les titres restent aussi pertinents dans la TOC, mais ce ne devraient pas être des h2. Il faudrait utiliser du CSS pour mettre le style visuel que vous voulez, pas des balises de titre.
La TOC pourrait être une grande liste <ul> qui contiendrait les sous-listes ul déjà présentes.
Dans la FAQ, les images ne sont pas correctement dotées d’un texte alternatif (alt )
Le diagramme devrait avoir un alt vide (alt="") puiqu’il n’ajoute pas d’information supplémentaire au texte qui le précède.
Les captures d’écran de Thunderbird devraient contenir les informations présentes sur l’image.
Exemple : "Capture d’écran de Thunderbird. Page de paramètres du serveur. Nom du serveur : imap.iroco.io. Port : 993. Nom d’utilisateur : demo@iroco.io. Paramètres de sécurité. Sécurité de la connexion : SSL/TLS. Méthode d’authentification : Mot de passe normal.
Ou alors un alt vide, mais il faudrait bien que toutes les informations soient décrites dans le paragraphe précédent. Il manque notamment les ports et la méthode d’authentification.
Sur app.iroco.co, les pages de connexion et d’inscription semblent très « zoomées ». Ce n’est pas du tout un problème a11y, au contraire, mais je me demandais si c’était volontaire.
Sur le blog, il y a aussi un problème sur les niveaux de titres où tout est h1. Je vous refais pas le speech ^^
Les images un peu design de la page d’accueil sont purement décoratives, elle n’apportent pas d’informations supplémentaires qui ne sont pas présentes dans le texte. Leur alt devrait être vide (alt=""). Pour l’instant le texte est en anglais et peu pertinent par rapport au reste du contenu.
Si c’est possible pour vous, et que ces retours vous intéressent, j’aimerais bien avec un compte de test sur votre espace connecté, pour tester les autres pages du logiciel
Oh ben on peut en partager un je pense, c’est vrai ! @mjal a un compte ici maintenant. Tu pourrais m’envoyer les identifiants en MP steuplait ? EDIT : c’est bon !
Coucou, voilà mes retours sur l’accessibilité de la webapp. Ce sont des corrections qui doivent être assez faciles à faire.
J’utilise parfois l’impératif par simplicité, mais ce ne sont que des conseils et mon avis bien entendu.
Retours a11y sur la webapp
Navigation
Voici les 3 premiers liens quand on navigue au clavier :
logo (labellisé « go to Iroco Home »)
« tableau de bord »
« compte »
C’est redondant, et ça peut être confusant (pour tout le monde, mais surtout quand on navigue au clavier et/ou utilise un lecteur d’écran). Et faire perdre du temps, parce qu’à chaque chargement de page, on doit les parcourir avant d’arriver à la suite.
L’option la plus clean est de supprimer les liens des 2 premiers items, pour éviter toute redondance.
Si vous tenez à ce que l’en-tête soit un lien, fusionner l’image et « Tableau de bord » en un lien, en enlevant l’aria-label de l’image et en mettant un aria-hidden sur le svg pour qu’il soit bien ignoré.
Si vraiment vous voulez avoir des liens séparés, au moins traduire le aria-label en français.
Tableau de bord ne devrait pas être un h1. Juste un p par exemple.
Le div qui contient le logo et « Tableau de bord » devrait avoir le role="banner" ou être un <header>.
Compte
Le texte « Votre utilisation : 121 Ko/5 Go (0%) » pourrait être mieux compréhensible en remplaçant le « / » par un « sur ».
L’image svg qui indique le pourcentage d’utilisation devrait avoir comme aria-label « Utilisation mail : 0% » au lieu de « React d3 speedometer » (ce qui n’a pas de sens pour un·e utilisateur·ice du site) (en ajustant la valeur bien sûr)
Phrase Vous pouvez fermer votre compte iroco en cliquant sur [ce lien]. : Le lien s’appelle « ce lien ». Pour un lecteur d’écran, si on navigue de lien en lien sans lire tout le texte (ce qui est courant), on n’aura pas le contexte de la phrase, et donc on ne saura pas à quoi réfère le lien appelé « ce lien ». Reformulations possibles : Cliquez ici pour [fermer votre compte], ou tout simplement [Fermer votre compte].
Mot de passe
Le contraste du bouton « Enregistrer » n’est pas assez important. On peut tester que le contraste est suffisant directement en faisant clic-droit → propriétés d’accessibilité
Alias
Le bouton + pour créer un alias devrait avoir un aria-label, « Créer un nouvel alias » par exemple.
Le bouton poubelle pour supprimer un alias devrait avoir un aria-label, « Supprimer l’alias exemple@iroco.fr » par exemple (en ajustant la valeur bien sûr)
FAQ
Comme pour les images de la FAQ publique, chaque image devrait soit être invisible avec un alt="" parce que toutes les informations dessus sont aussi présentes dans les paragraphes qui l’entourent, soit contenir une description fidèle de ce qu’on voit à l’écran.
Ces quelques éditions changeront assurément la donne, entre un service désagréable à utiliser, avec des parties complètement inaccessibles (je pense à la création /suppression d’alias), en un service fluide et agréable ! Car l’appli est minimale, claire, et vient à l’essentiel, ce qui sont des grandes qualités
L’application de webmail est entièrement inaccessible pour une navigation au clavier et au lecteur d’écran. Ça serait utile d’écrire ça quelque part, en conseillant l’utilisation de Thunderbird à la place.
Hello, je trouve le parcours utilisateur pour créer un email avec un nom domaine personnalisé vraiment facile et rapide et beau visuellement De plus vous êtes très transparent sur votre infrastructure.
Pour ma part, j’ai essayé de suivre au mieux la fameuse « Liste de conformité à la Charte CHATONS - Partie technique ».
Retour technique
Mieux vaut désactiver TLSv1.0 et TLSv1.1 sur les mail
Je pose la question sur la politique de confidentialité doit mentionner spécifiquement les emails comme données personnelles / sensibles
Je n’ai pas trouvé l’info sur la durée de rétention des logs sur le site (le blog en parle pour la partie des logs gérée par InfluxDB). Pouvez-vous préciser l’information ?
Le code source du site est-il ouvert ? (Le dépot iroco-co/landing semble archivé).
Le code source de app.iroco.co est-il ouvert ?
Pour mail.iroco.co, utilisez-vous une version modifiée de snappymail ?
Avez-vous envisagé de publier votre code sur des forges logicielles plus libres (que github/microsoft) ? (Ce n’est pas une nécessité mais toujours un plus).
Notes sur la configuration mail
Plutôt de la curiosité sur le protocole mail, comme vous êtes experts : Les enregistrements DNS SPF pour iroco{.fr,.co,.io} et ceux qu’il faut ajouter sur un nom de domaine custom utilisent ~all. Pourquoi pas -all qui est plus strict ?
Pour configurer un email avec son propre nom de domaine, à quoi servent ces entrée DNS : « smtp IN MX 5 smtp » et « imap IN MX 10 imap » (ma compréhension est que c’est seulement utile pour recevoir des mails à user@smtp.mondomaine.tld, etc. mais je loupe peut-être quelquechose)
Je ne sais pas si vous savez qu’il est possible de faire pointer les enregistements DMARC DKIM et SPF vers une autorité centrale, ce qui peut simplifier les mises à jour (ex: paragraphe 3. de https://guide.deuxfleurs.fr/operations/email-personnalise/)
Je ne suis pas du tout sur de ça mais j’ai un doute: Les reports de iroco{.co,.io} sont envoyés à postmaster@iroco.FR. C’est un domaine différent, il manque peut-être ces entrées DMARC : _co._report._dmarc.iroco.fr. 3600 IN TXT « v=DMARC1 » _io._report._dmarc.iroco.fr. 3600 IN TXT « v=DMARC1 » (cf. https://dmarc.org/2015/08/receiving-dmarc-reports-outside-your-domain)
Et voici un premier retour sur la partie générale, en suivant la Liste de conformité à la charte - Partie Général. En commençant par un bravo pour ce site agréable, les explications claires et transparentes.
J’espère ne pas faire trop d’erreur (toutes mes excuses sinon)
Premier retour sur l'audit général
Le webmail est annoncé dans la candidature mais n’est pas accessible via votre site : est-ce volontaire ? (Note : le lien est cependant accessible depuis https://app.iroco.co/account une fois identifié)
La FAQ, les mentions légales, le paragraphe « Hébergement engagé » de la page à propos, les CGV mentionnent encore Eolas comme hébergeur alors que l’hébergement serait chez OVH d’après votre candidature.
Bravo pour la gestion d’audience respectueuse. Cependant il semblerait que le bouton pour la gestion de la mesure d’audience soit cassé (CSP ? ) :
Nous n’avons pas trouvé d’information (note, document…) concernant l’engagement des admin sys pour répondre au critère : « Les personnes qui ont des accès administrateurs, bénévoles ou salariées s’engagent sur une charte concernant des points de confidentialité et de prudence. »
Les CGV sont assez techniques. Serait-il possible d’avoir « Une version courte / condensée proposée afin de faciliter la compréhension du texte. » ou un paragraphe ou un lien qui renvoie vers les messages clefs très clairs mis en avant dans d’autres sections de votre site (Foire Aux Questions) svp ?
Il serait également intéressant de mettre en avant ce qui est par ailleurs mentionné dans d’autres pages du site (Foire Aux Questions) : le non-accès au contenu des mails, afin de répondre positivement au critère : "Le futur CHATON s’engage dans ses CGU à ne s’arroger aucun droit de propriété des contenus, données et métadonnées produits par les hébergées ou les utilisateurs et utilisatrices."
Une question à la lecture des CGV pour la gestion des données : combien de temps les archives sont accessibles après résiliation ? Quand a lieu la suppression des données ?
En complément, les applications de votre infra et ou directement accessibles (newsletter, mesure d’audience…) semblent répondre aux critères également.
Je pourrais peut-être revenir avec des compléments mais l’essentiel a déjà été vérifié et il paraissait préférable de communiquer le maximum au plus vite.
Merci au passage pour les réponses à toutes nos précédentes questions et demandes
Il restait quelques points à vérifier sur la partie générale. Seul nouveau point à apporter : l’utilisation de hcaptcha.
C’est un sujet un peu épineux, à voir s’il s’inclurait dans la section « services anti-spam propriétaires » de la liste d’exceptions. Lors d’un précédent audit, mcaptacha avait été mentionné, il existe d’autres solutions on premise annoncées sans partage ip (altcha ? …)
Les vérifications des différentes parties sont normalement terminées pour votre candidature, nous restons bien évidemment disponibles si besoin pour la période de modification.
Encore merci pour toute la disponibilité pendant la phase d’audit.
Merci à tous pour vos audits détaillés et qui vont nous permettre d’améliorer plus encore notre service. Nous allons digérer tout ça et alimenter notre backlog.
Pour le hCaptcha c’est keila qui l’utilise. Pour notre part (sur la page d’inscription) nous avons privilégié altcha.. S’il faut le modifier ça demanderait une PR sur keila.
Le webmail est annoncé dans la candidature mais n’est pas accessible via votre site : est-ce volontaire ?
Nous avons corrigé ça sur le site.
Les CGV sont assez techniques. Serait-il possible d’avoir « Une version courte / condensée proposée afin de faciliter la compréhension du texte. » ou un paragraphe ou un lien qui renvoie vers les messages clefs très clairs mis en avant dans d’autres sections de votre site (Foire Aux Questions) svp ?
Il faut qu’on vérifie. Nous l’avions fait avec les cofondateurs d’iroco, avocats. Nous avions essayé de faire au plus simple et lisible. Nous pouvons tenter une version plus courte et la leur soumettre.
Une question à la lecture des CGV pour la gestion des données : combien de temps les archives sont accessibles après résiliation ? Quand a lieu la suppression des données ?
Les archives des sauvegardes sont conservées 6 mois.
Je n’ai pas trouvé l’info sur la durée de rétention des logs sur le site (le blog en parle pour la partie des logs gérée par InfluxDB). Pouvez-vous préciser l’information ?
Oui comme mentionné dans l’article, nous conservons les logs 1 mois (28 jours plus exactement). Elles sont renouvelées avec logrotate.
Le code source du site est-il ouvert ? (Le dépot iroco-co/landing semble archivé).
Pour mail.iroco.co, utilisez-vous une version modifiée de snappymail ?
Non c’est la version d’origine.
Avez-vous envisagé de publier votre code sur des forges logicielles plus libres (que github/microsoft) ? (Ce n’est pas une nécessité mais toujours un plus).
Oui c’est sur codeberg.
Sur app.iroco.co, les pages de connexion et d’inscription semblent très « zoomées ». Ce n’est pas du tout un problème a11y, au contraire, mais je me demandais si c’était volontaire.
Oui c’était pour que ce soit bien clair pour tout le monde.
Et pour le code de l’app, nous allons également l’ouvrir. Nous voulons vérifier qu’il n’y a pas de « secrets » qui trainent dans un des commits avant cela.
Pour l’hébergement nous avons aussi corrigé le site pour remplacer Eolas par OVH.
dans votre FAQ Foire Aux Questions une référence à Eolas hors vous avez changé pour OVH
Le lien vers les sources en bas de page redirige vers Github au lieu de Codeberg
J’aurai une question technique, vous faites tourner vos services d’envoi de mail seulement sur une IP ? Je pensais que pour un service comme le votre il aurait fallu 3/4 IPs pour contourner des blocages lorsque ça arrive le temps de se faire débloquer ? Je ne suis pas spécialiste des mails.
Pour Keila, que je viens de découvrir vous utilisez votre serveur d’envoi ?
Nous avons corrigé la référence à Eolas et le picto + lien dans le footer pour codeberg.
Pour l’instant oui c’est une seule IP. Nous n’avons pas eu de problème de déliverabilité (sauf quelques mails dans les spam gmail), même en envoyant notre newsletter à env. 200 personnes pour l’instant.
Du coup nous avons pris le parti de faire évoluer notre infrastructure avec les besoins. Nous avons un HAproxy en front, et c’est « assez facile » de déployer d’autres machines postfix derrière si nécessaire.
Et oui nous utilisons également notre serveur d’envoi pour keila.
Vous redoutez des blacklistages ?
Par ailleurs nous avons aussi corrigé la plupart des problèmes d’accessibilité remontés plus haut (notamment les problèmes de hiérarchies dans l’app et dans le site).
Bonjour !
On est en train de formaliser le vote de hadoly… Et je me pose qq questions en relisant ce fil. @mjal c’est moi qui ai rêvé ou tu as modifié ton analyse de sécurité ? Il me semblait avoir lu des trucs notamment sur les rua pour la policie dmarc ?
C’est corrigé par @bam ?
Idem TLS 1.0 /1.1 on peut considérer les conserver pour éviter l’obsolescence de certains appareils ?
Merci pour vos réponses
