Un jour, la demande arrive : « et si les utilisateurs pouvaient commenter ? ». Puis viennent les profils, les abonnements, un fil d’activité. Sur la maquette, c’est un champ de texte et un bouton. En production, c’est un autre métier : dès que vos utilisateurs peuvent publier quelque chose que d’autres liront, votre application héberge du contenu, et cela entraîne des obligations précises, techniques et légales. Mieux vaut les connaître avant de chiffrer.
Ce que les stores exigent avant même la publication
Apple est explicite. Sa règle 1.2 impose à toute application avec du contenu généré par les utilisateurs ou un service de réseau social quatre choses : un moyen de filtrer les contenus répréhensibles avant leur publication, un mécanisme de signalement avec des réponses rapides, la possibilité de bloquer les utilisateurs abusifs, et des coordonnées publiées pour vous joindre. Une application qui n’a pas ces outils risque le refus à la validation, ou le retrait plus tard.
Google Play va dans le même sens et ajoute des exigences : l’utilisateur doit accepter des conditions d’utilisation qui définissent les contenus interdits avant de pouvoir publier, l’application doit modérer de façon raisonnable, et une application sociale doit permettre de signaler des contenus et des utilisateurs, et de bloquer ces derniers. Enfin, les deux stores exigent qu’un compte créé dans l’application puisse y être supprimé, et Google demande en plus une page web pour en faire la demande.
Ce que la loi européenne ajoute
Depuis le 17 février 2024, le règlement européen sur les services numériques, le Digital Services Act, s’applique à tous les services qui hébergent des contenus fournis par leurs utilisateurs. Une partie de ses règles ne vise que les grandes plateformes, et les micro et petites entreprises sont dispensées de toute une section du texte. Mais un socle s’applique quelle que soit la taille :
- Un point de contact unique (article 12), pour que vos utilisateurs puissent vous joindre directement, et pas uniquement par un robot.
- Des conditions générales qui décrivent votre modération (article 14) : ce qui est restreint, avec quels outils, et quelle part revient à une personne.
- Un mécanisme de notification (article 16), facile d’accès, qui permet à quiconque de signaler un contenu illicite, avec un accusé de réception et une décision communiquée à l’auteur du signalement.
- Un exposé des motifs (article 17) : quand vous retirez un contenu, en réduisez la visibilité ou suspendez un compte, la personne concernée doit recevoir une explication claire et spécifique.
Rien de tout cela n’est insurmontable, mais chaque point est un écran, un e-mail ou un outil interne à construire. Ce n’est pas un avis juridique : pour un cas précis, un juriste reste la bonne personne. C’est en revanche une liste qui doit figurer dans le périmètre dès le départ.
La modération est un produit, pas un formulaire
Un bouton « signaler » qui envoie un e-mail dans une boîte que personne ne lit ne protège ni vos utilisateurs ni votre fiche sur les stores. Une modération qui tient la route se conçoit comme une fonctionnalité à part entière, avec ses propres écrans côté équipe :
- Une file des signalements triée, avec le contexte du contenu, son auteur et ses antécédents.
- Des gestes gradués : masquer sans supprimer, avertir, suspendre, en gardant une trace de chaque décision et de son motif.
- Des protections automatiques : un filtre de mots, des plafonds de publication pour freiner le spam, un âge minimum à l’inscription.
- Un blocage qui bloque vraiment : une personne bloquée ne doit plus vous voir nulle part, ni dans les commentaires, ni dans la recherche, ni dans les notifications.
Reste la question que l’on oublie le plus souvent : qui traite les signalements, et en combien de temps, un dimanche soir ? La réponse n’est pas technique, mais elle conditionne la technique : plus l’équipe est petite, plus les protections automatiques doivent porter.
Dès que vos utilisateurs publient, vous n’éditez plus seulement une application : vous tenez un lieu. Et un lieu se garde.
Le serveur décide, l’écran affiche
Une règle traverse tout le reste : ce qu’une personne a le droit de voir se décide sur le serveur, jamais seulement dans l’interface. Masquer un commentaire à l’écran alors que le serveur continue de l’envoyer, c’est le laisser lisible par quiconque inspecte l’application. C’est l’un des défauts que nous retrouvons le plus souvent dans les applications que l’on nous demande de reprendre.
Nous l’avons appliquée à la lettre sur Nakama, notre propre réseau social de l’anime et du manga. Le voile qui protège des spoilers, la modération, le blocage : tout est tranché côté serveur, pour chaque personne. Construire ce produit nous a appris que la partie sociale, celle qu’on dessine en une après-midi, est aussi celle qui demande le plus de soin.
Comment le budgéter
Si votre produit a besoin d’une dimension sociale, elle se cadre comme le reste, avec un périmètre de départ réaliste : commencer par des commentaires bien modérés vaut mieux qu’un fil complet que personne ne surveille. Et si le cœur de votre produit, c’est justement que vos utilisateurs se parlent, c’est exactement le type de projet que nous menons en ingénierie produit. Parlons de votre application : nous vous dirons ce que la partie sociale va réellement demander.