@david-evan

III.-1. Les personnes dont l'activité est d'éditer un service de communication au public en ligne mettent à disposition du public, dans un standard ouvert :

a) S'il s'agit de personnes physiques, leurs nom, prénoms, domicile et numéro de téléphone et, si elles sont assujetties aux formalités d'inscription au registre du commerce et des sociétés ou au répertoire des métiers, le numéro de leur inscription ;

b) S'il s'agit de personnes morales, leur dénomination ou leur raison sociale et leur siège social, leur numéro de téléphone et, s'il s'agit d'entreprises assujetties aux formalités d'inscription au registre du commerce et des sociétés ou au répertoire des métiers, le numéro de leur inscription, leur capital social, l'adresse de leur siège social ;

c) Le nom du directeur ou du codirecteur de la publication et, le cas échéant, celui du responsable de la rédaction au sens de l'article 93-2 de la loi n° 82-652 du 29 juillet 1982 précitée ;

d) Le nom, la dénomination ou la raison sociale et l'adresse et le numéro de téléphone du prestataire mentionné au 2 du I.

2. Les personnes éditant à titre non professionnel un service de communication au public en ligne peuvent ne tenir à la disposition du public, pour préserver leur anonymat, que le nom, la dénomination ou la raison sociale et l'adresse du prestataire mentionné au 2 du I, sous réserve de lui avoir communiqué les éléments d'identification personnelle prévus au 1.

Les personnes mentionnées au 2 du I sont assujetties au secret professionnel dans les conditions prévues aux articles 226-13 et 226-14 du code pénal, pour tout ce qui concerne la divulgation de ces éléments d'identification personnelle ou de toute information permettant d'identifier la personne concernée. Ce secret professionnel n'est pas opposable à l'autorité judiciaire.

quelques recherches sur le BFF (Backend For Front) :
• https://www.linkedin.com/pulse/bff-backend-frontend-pattern-microservices-arpit-bhayani/
• https://blog.octo.com/les-indispensables-dun-projet-frontend-un-backend-for-frontend-une-api-sur-mesure/

Pour résumé et si j’ai bien tout compris, l’utilisation d’une couche ou application BFF est utile lorsque le système possède des interfaces différentes, afin d’avoir un rendu de données spécifique en fonction du besoin de chacune desdites interfaces. Cela présente notamment l’avantage d'économiser de la bande passante via l'optimisation des requêtes suivants le besoin ; c’est le travail que fait le BFF.
Autres avantages :
• Une séparation nette des responsabilités entre développeur backend et frontend :
o Les développeurs backend mettront à disposition des API “générique” et contenant des données brutes.
o Tandis que les développeurs frontend pourront spécifier leurs besoins de données en fonction des interfaces.
• Optimisation des requêtes selon les besoins.
• La maintenance corrective spécifiques pour chaque BFF/interfaces.
• L’isolation de chaque interface et leur BFF associé
• Les developpeurs frontend peuvent faire évoluer les requêtes suivants leur convenance.
• Le bakend quant à lui fourni une API qui est indépendante des interfaces.
• Certaines données sensibles peuvent être cachées à des clients spécifiques.
Inconvénients :
• Une couche et un service supplémentaire à déployer, maintenir et superviser.
• L’ajout d’une couche peut engendrer une augmentation légère de la latence.
• Les développeurs frontend doivent gérer en supplément un backend.
• Duplication de code.
Ci-dessous un schéma générique représentant une implémentation BFF.

[...] je pense qu’il serait optimal d’avoir un BFF unique par interface et pour plusieurs entrées telles que le site Web et l’application mobile, notamment via l’utilisation de la solution GraphSQL, qui permet de n’avoir qu’une seule couche BFF pour des entrées multiples (voir la partie gauche du schéma ci-dessus). Autrement dit, on aurait pour chacune des deux interfaces de notre projet un BFF qui fait le pont entre l’API du backend, et notamment celles pour les données, et les deux interfaces accessibles via mobile et site Web.
Cela présenterai les avantages suivants en plus de ceux mentionnés plus haut :
• Une seule interface connectée à un unique BFF, et accessible via plusieurs entrées ou terminaux (fixe et mobile), permettrait :
o de limiter la duplication de code, de la standardiser notamment avec du HTML 5 ;
o de limiter la latence, limitant le nombre d’interfaces et donc de BFFs ;
o de faciliter la maintenance, pour les mêmes raisons susmentionnées, et de fait d’alléger la charge de travail des développeurs frontend.
L’objectif étant de pallier du mieux possible aux inconvénients vus plus haut.

Ci-dessous ma vision [...] (j’ai uniquement mis les interfaces concernées par le BFF) :

https://github.com/marketplace/actions/run-pyspelling-as-a-github-action#:~:text=A%20Github%20Action%20that%20spell,provided%20by%20the%20repository%20owner.

Follow up for: #10