Hello,

Aujourd’hui, on va parler sécu !

Je sais que c’est un sujet qu’on à tendance à faire glisser sous le tapis 🙄

Alors on s’est dit que ce serait une bonne idée de vous montrer comment vous pouvez offrir des sites plus robustes à vos clients sans être expert en sécurité.

Si le contenu vous apporte de la valeur, vous pouvez nous soutenir en invitant vos amis à s'abonner ici.

Sans plus tarder, entrons dans le vif du sujet !

🔍 Dans cette édition…

• Le futur des visual builders : le text-to-component 🤯

• 2 argumentaires pour mieux vendre les architectures composables à vos clients 🤑

• Le meilleur framework à intégrer avec Strapi ⚔️

Mais avant toute chose…

🐣 Le tweet de la semaine

Je pense que ce tweet est une très bonne illustration du syndrome de l’objet brillant qui atteint pas mal de devs ces jours-ci…

Forcément, quand on voit les possibilités de l’IA, on a envie de l’utiliser partout ! Ce qui est frustrant, c’est justement de ne pas avoir le temps de tout faire 🙁

🤔 La question de la communauté

Aujourd’hui, on va explorer un sujet très important, puisqu’il s’agit de la sécurité. À partir du moment ou votre site est en ligne, il est la cible potentielle d’attaques, d’où la question du jour :

La Jamstack permet-elle d’améliorer la sécurité d’un site web ?

On entend souvent dire que les sites Jamstack offrent une meilleure sécurité par rapport aux architectures traditionnelles. Mais qu’en est-il réellement ?

Tout d'abord, il faut savoir que l’idée derrière la Jamstack est de générer des sites statiques, qui ne dépendent pas d'un serveur pour chaque requête d’utilisateur. Les pages web sont générées au préalable et sont stockées dans un cache.

Ainsi, lorsque l'utilisateur visite un site Jamstack, il accède directement à la page en cache sans que celle-ci ne doive être regénérée à chaque fois.

Cela réduit considérablement les risques de vulnérabilités, notamment en éliminant la possibilité d'attaques par injection de code malveillant.

De plus, les sites Jamstack sont souvent servis via un CDN (Content Delivery Network), qui distribue le contenu à partir de différents serveurs dans le monde entier. Les CDN fournissent également une couche de sécurité supplémentaire, car ils peuvent détecter et bloquer les attaques DDoS (Déni de Service Distribué) en répartissant la charge sur différents serveurs.

Enfin, sur un site Jamstack, on utilise souvent des services tiers via des API pour les fonctionnalités dynamiques telles que les formulaires ou les commentaires, plutôt que d'exécuter du code côté serveur.

Ainsi, on dilue les risques, puisqu’on délègue la gestion de la sécurité côté serveur à une entreprise dont c’est le seul rôle.

Cela limite donc les risques de sécurité liés à l'exécution de code côté serveur et réduit également la charge sur le serveur principal.

En résumé, la Jamstack offre une meilleure sécurité en utilisant des sites statiques qui ne dépendent pas d'un serveur pour chaque demande, en distribuant le contenu via un CDN pour une protection DDoS accrue, et en limitant les risques de sécurité liés à l'exécution de code côté serveur.

Bien entendu, il y aurait un milliard d’autres choses à raconter sur ce sujet. Si le sujet de la sécurité vous intéresse particulièrement, n’hésitez pas à nous le faire savoir en répondant à cet email !

👉 Vous aimeriez poser une question sur la Jamstack ? Répondez à ce mail et nous y répondrons dans une prochaine édition !

🥪 JamSnacks

• On commence très fort avec cet article qui présente une démonstration assez incroyable de l’intégration de Chat-GPT à Builder.io (un site builder qui fait également office de CMS headless). C’est donc officiel, on peut créer un site web simplement en le décrivant avec des mots 🤯

• On poursuit avec ce chouette article qui explique les défis auxquels font faces les marques pour leurs boutiques en ligne, et comment il peuvent être relevés grâce à l’architecture “composable” (ou le site est divisé en modules qui fonctionnent indépendamment, ce qui est rendu possible par les CMS headless).

• Une nouvelle version de Plasmic est arrivée ! Elle amène notamment la possibilité de gérer les formulaires directement depuis le site builder (sans toucher au code), ainsi que l’intégration de nouveaux composants pré construits comme les Data Table ou les Page Layout.

• Encore un article qui nous explique les avantages du ecommerce headless. Au cas ou vous ne seriez pas encore convaincu 😉

• Strapi nous propose un petit comparatif entre Next.js et SvelteKit (le nouveau “cool kid” du quartier), afin de déterminer lequel se marie le mieux avec Strapi. Spoiler alert : il n’y a pas de mauvais choix, juste une question de préférences 🤷‍♂️

• Et on termine avec un superbe article écrit par Jean-Philippe, qui travaille avec nous à Pickbeam. Il s’agit d’un superbe tuto pour créer un champ personnalisé sur Storyblok qui utilise Iconify, afin que les utilisateurs puissent ajouter les icônes de leur choix depuis le CMS 🥳

Et voilà, c’est déjà tout pour cette semaine !

J’espère de tout cœur que cette édition vous à plu, si c’est le cas :

👉 Pensez à la partager à vos amis 💌

👉 Si vous avez des idées pour améliorer la newsletter, répondez simplement à ce mail. Nous lisons toutes vos réponses !