Kulgar

Ouip, en effet, je parlais d'un blog personnel, je ne savais même pas que je pouvais avoir le droit de faire des publications sur ce site. Merci Aenoa.

Merci Après tout, si je me suis inscrit ici c'est pour partager et échanger mes connaissances, je ne suis donc pas avare en explications, surtout dans un domaine qui me passionne. _AT_Aenoa : Comme tu le dis, après relecture, ça ressemble beaucoup à un "article". Ca ne te dérange pas si je reprends tes questions pour transformer tout ça en un article de blog ? Je pense que ça pourrait sûrement être utile à un bon nombre de Webmasters qui pourraient, de cette façon, tomber dessus lors de recherches Google.

Alors, voilà exactement mon champ d'expertise xD. Alors déjà, reprenons les bases. DDoS est une attaque bien plus puissante qu'un simple DoS. Un DDoS, c'est comme un DoS mais avec un D en plus pour "distribué". Comment fonctionne cette attaque ? En générale, il s'agit, pour un pirate, d'envoyer une requête depuis un serveur pirate vers plein d'ordinateurs contaminés par un de ses virus (aussi appelés Zombies) pour que chaque ordinateur envoie une requête ou un paquet vers la cible. La cible recevant tellement de paquets, ne peut les traiter tous, et affiche donc "trop de trafics" pour les futurs connectés. C'est ce qu'on appelle une attaque de type : distributed denial-of-service attack, car on déni le service (autrement dit, on le met totalement HS). Ce type d'attaque, sur un site Web, peut être faite de deux manières (les plus communes du moins) différentes : - Soit c'est le serveur qui est directement attaqué (ou le routeur, ou un équipement réseau entre Internet et le serveur, peu importe lequel), dans ce cas il s'agit d'une attaque de type "réseau" et il faudra fournir les logs Réseaux à la police. - Soit c'est le site Web qui est directement attaqué par des requêtes longues à gérer, comme le rafraîchissement d'une page contenant de la vidéo, ou la recherche d'articles, ça fait travailler le serveur donc c'est privilégié par les pirates. On parle plutôt là d'attaque de type "applicatif" et il faudra donc fournir les logs des requêtes (donc du site Web) à la police. Comment détecter l'une ou l'autre des attaques ? La première, vous ne pouvez plus accéder au serveur, ni au site... Vous ne devriez même plus être en mesure de vous connecter au serveur en tant qu'admin. Dans ce cas => contacter OVH. La deuxième, vous aurez sûrement (au mieux) une page indiquant que le site est surchargé et qu'il faut augmenter les capacités du serveur. Contacter également OVH, et couper l'accès au site attaqué, ça arrêtera immédiatement l'attaque et protègera les éventuels autres sites / services d'un déni de service par ricochet (comme j'appelle ça, j'explique ce que c'est par la suite). Ensuite... pourquoi DDoS est bien plus puissante qu'un simple DoS ? Déjà parce que l'attaque ne provient pas d'un unique ordinateur. Ensuite parce que comme ce sont des ordinateurs Zombies qui font l'attaque, ce sont des ordinateurs de particuliers et donc, connaître leurs adresses IP ne sert à rien (beh oui, pas la faute des particuliers s'ils ont un ordi virussé). Donc les logs seront très certainement inexploitables. Enfin, si, juste pour voir qu'il s'agit effectivement d'un DDoS. Il n'y a strictement (et normalement) AUCUN moyen de remonter jusqu'au pirate (sauf s'il est maladroit, mais un pirate, c'est rarement maladroit). Le pirate n'a fait qu'envoyer une simple requête à un serveur qui l'a relayée vers tous les ordinateurs Zombies. Cette requête ne se retrouve évidemment pas dans les attaques depuis les ordinateurs Zombies. Ce qui est ennuyeux aussi, avec ce type d'attaque, c'est qu'il n'est nul besoin d'être un véritable pirate pour l'exécuter. Les pirates "louent" ce service (si si, je déconne pas). Il est donc possible de leur acheter un "temps" de déni de service. Par exemple : - Je veux un DOS de 48h sur ce site - D'accord, ça vous coûtera 5000 - Vendu ! Hé ouais, les pirates sont sans scrupules et ont tout de suite vu ici, une opportunité de se faire de l'argent en exploitant les guerres que se livrent les sites concurrents. De plus, en général, s'ils sont attrapés, ils arrivent à bien s'en sortir, certes ils ont piraté, mais ils ont été payés pour ça, ils proclament donc que s'ils n'avaient pas été payés, ils n'auraient jamais attaquer, et rejettent donc la faute sur les entreprises qui ont fait appel à leur service. C'est moche... mais c'est la réalité du piratage. En fait, il existe bien un moyen de remonter jusqu'au pirate. Mais, c'est une technique également de "piratage" que certains experts en sécurité Web peuvent mettre en oeuvre, et c'est tout autant condamnable par la police, même s'il s'agit là d'attraper un malfaiteur... Bref, si c'est la police qui le fait (pour que ça soit légal), elle aura besoin des logs. Concernant le logiciel de surveillance réseau, ça s'appelle aussi un "sniffer" car on "snif" le réseau. Très utilisé par les pirates et par les pro de la sécurité Web, je ne peux que te conseiller Wireshark! Qui est entièrement gratuit. Avec ça, tu verras tout ce qu'il se passe sur ta machine au niveau réseau : les paquets qu'elle reçoit et ceux qu'elle envoie. Porter plainte ? Oui, il y a toujours utilité. Notamment, tu n'es pas le seul dans cette situation, comme tu l'as si bien dit. Ca peut notamment faire qu'OVH renforce la sécurité naturelle de ses serveurs (ils sont sensés être au courant si tu portes plainte). Et, à force de plaintes et d'archivages de logs, peut-être que la police finira par trouver un truc qui leur permettra de remonter jusqu'aux pirates. Il y a de très bons analyseurs de logs dans la police, allant même jusqu'à analyser l'hexadécimal des paquets... Chose qui, je le sais par expérience, demande énormément de connaissances et compétences techniques. Pour répondre à la dernière question, comme je le disais, ça dépend du type d'attaque DDoS. Soit c'est une attaque directe sur un équipement réseau d'OVH ou du serveur. A ce moment là, tu ne peux rien y faire, sinon le signaler à OVH qui sera très certainement déjà au courant (en général, ils aiment pas se faire pirater les hébergeurs Webs, et sont très réactifs). Soit c'est un DDoS sur ton site, via une multitude de requête effectuée toutes les secondes. A ce moment là, c'est le serveur qui travaille directement, donc tout dépend de comment il est configuré : - soit ses ressources sont partagées par toutes les applications et dans ce cas, tous les sites et autres applications seront atteintes (jusqu'à quel point, je ne saurais le dire, c'est ce que j'appelle le DDoS par ricochet). - soit ses ressources sont bien "fragmentées et séparées" et une certaine quantité est alloué à ton site, dans ce cas tu ne perdras de la disponibilité seulement que vers ton site. En tout cas, avec du DOS, tu ne perds que de la disponibilité. Tu ne perds pas d'intégrité ni de la confidentialité. Ce sont les 3 critères principaux utilisés en gestion de la sécurité (DIC) pour catégoriser les effets des attaques. Bon, après, je ne te cache pas qu'il existe des attaques faisant les 2 en même temps, un DoS + récupération de fichiers dès lors qu'on a atteint un buffer overflow (dépassement de mémoire, après ça, les équipements réseaux ont tendance à faire n'importe quoi). Tiens, je donne un exemple : à une époque, les Switch étaient programmés pour, qu'en cas de surcharge, ils repassent en fonctionnement HUB. Les pirates ont rapidement exploité cette faille, en faisant un petit DOS sur un switch, ils avaient ensuite accès à tous les ordinateurs du réseau puisque le switch était repassé en broadcast (i.e. il relaie tous les paquets à tous les PCs qui lui sont raccordés sans se soucier des adresses IP d'origine et de destination). Bon... J'ai écrit beaucoup et je me suis lâché, désolé pour le trop plein d'informations. Mais en sécurité Web, mieux vaut plus que pas assez . En espérant que cela réponde à tes questions, si tu en as d'autres, hésite pas . Kulgar. [edit] J'ai mis un peu de mise en forme, j'ai eu peur que ça ne soit pas digeste.

Oups, pardon à voir la façon dont tu écrivais, j'ai cru que tu étais pro. Ruby sur les rails, ROR, Ruby On Rails, c'est un framework Web... En très gros, un ensemble de fonctions et fonctionnalités pré-programmées à l'aide du langage Ruby permettant de faciliter grandement la vie du développeur et accélérant le développement de sites Web. Dans le même style, tu as Zend et Symfony pour PHP (un petit google sur ces mots clés te permettra d'en apprendre plus si tu es intéressée ). Je vais essayer en incluant du script dans la liste, je te tiens au courant de mes tests. Mais à priori, ça devrait passer sans soucis. Ou plutôt, je ne vois pas pourquoi javascript ferait échouer le test, mais bon, on sait jamais, tu as raison.

Wolf, ce que Arlette veut dire c'est que la négligence ne peut pas être punie par la loi. L'incitation au vol, ça peut effectivement être répréhensible. Toutefois la loi est claire : on est innocent sauf preuve du contraire. Ca s'applique parfaitement sur le Web, les personnes laissant un accès aussi simple à des informations à priori confidentielles sont jugées innocentes (i.e. on pense d'abord à de la négligence). Si ensuite il y a exploitation malicieuse de ces informations ou que quelqu'un porte plainte, une enquête pourrait conduire à découvrir que cette maladresse était intentionnelle pour que des complices pirates récupères ces infos... Bref, tout ça pour dire : on ne peut pas punir la négligence (imaginez, ça conduirait à des aberrations...) mais on peut punir une faute intentionnelle si on a de quoi prouver qu'elle était intentionnelle (comme l'incitation au vol). Arlette, ton exemple de la porte me fait penser combien l'application des lois informatiques et celles de la vie de tous les jours peuvent totalement diverger parfois... Je pense notamment aux chercheurs de failles de sécurité. Combien de fois j'ai entendu l'histoire classique suivante : "Un chercheur (ou une équipe) doué en informatique et spécialisé dans la découverte de failles de sécurité de logiciels et de sites, en découvre effectivement une dans un logiciel hyper commercialisé dans le monde entier : Widon 7. Le chercheur, alarmé par cette faille pouvant compromettre l'ensemble des systèmes de la planète, envoie un rapport bien détaillé à Misoft sur la faille : sa cause, sa position, sa possible exploitation, les effets d'une attaques et (en général) comment la résoudre. Misoft reçoit ce rapport et se dit : au secours !! Un pirate a découvert une faille dans notre super logiciel et nous nargue en nous envoyant tout un rapport ! Misoft fait alors un procès à ce pauvre chercheur qui, bien évidemment, perd (car Misoft a toute une batterie d'excellents avocats) et se retrouve ruiné (voire emprisonné)." Bon, il se trouve que Microsoft prend très bien les retours des failles, pour ça que j'ai mis Misoft. Mais oui, c'est très différent de l'exemple de la porte... Des chercheurs informent sur une faille de sécurité et certaines entreprises cherchent à les condamner plutôt qu'à dépenser leurs sous pour résoudre cette faille. C'est ridicule, mais tellement commun comme histoire.

Ah c'est bizarre ça... Il me semble pourtant que ça ne passait pas la validation de l'outil que j'ai mis en lien justement. Ou alors j'ai rêvé ? Ou alors j'ai confondu avec une autre balise ? Bon, je viens de refaire vite fait un test avec l'outil, ça passe les <div> dans les <li>. Mea Culpa. Enfin, des divs dans des li, ça te fait pas bizarre quand même ? Nullette : moi j'ai commencé à utiliser ce validateur, car je développe en Ruby On Rails, et il y a pas mal de code HTML remplacé par des fonctions Rails (qui génèrent ensuite le code). Je voulais donc vérifier que mes sites passaient la validation. Ce qui est rassurant c'est que la majorité des erreurs que j'ai eues étaient surtout liées aux... boutons des réseaux sociaux (et à mes listes ul/li, d'où ma confusion de tout à l'heure).

Oh, tu sais, la première chose qu'on apprend dès qu'on entre dans une formation en sécurité Web, c'est que la faille de sécurité principale c'est l'utilisateur. Dans 70% à 80% des cas, les problèmes de sécurité sont liés à des utilisateurs (mauvaises manipulations, inattentions, crédulités, et j'en passe). Les 20% restant ce sont les attaques intentionnelles. Franchement si tu grattes un peu de ce côté ça te fait vite froid dans le dos de voir à quel point les utilisateurs et consommateurs ne sont pas responsables justement. Quand je vois la tonne de chose que j'ai apprise dans le domaine de la sécurité Web et dont je n'avais même pas idée... La tonne de failles, la tonne d'actes non malicieux mais résultant quand même en failles de sécurité et surtout la tonne des attaques ingénieuses des pirates... je me dis qu'un utilisateur lambda ne pourra jamais être responsable sur le Web... ou alors il faudrait une sensibilisation à très grande échelle. Franchement parmi tous les retours d'expériences de professionnels et chercheurs, mais aussi à travers mon passage à HSC, j'en ai vraiment entendu des vertes et des pas mûres. Les utilisateurs n'ont même pas idée du dixième de toutes les menaces qui trainent sur le Web. Quand on passe en formation sécurité Web, étrangement on devient vite parano. Raph : piouf, heureusement pour les numéros de CB. Sinon, quel bon filon pour un pirate : des numéros de CB gratos et rapidement acquis ! xD

Pour le coup, je suis d'accord avec toi Arlette. Mais les sites marchands manipulent tout de même des données sensibles, fort heureusement il n'y a pas les numéros de carte bancaire sur ces factures (j'espère ? XD) mais si ils y étaient ça serait vraiment très grave, et là c'est le jackpot pour les pirates. C'est sûr, on ne peut pas condamner les sites pour leur négligence (sauf si c'est délibéré bien entendu).

Au plaisir Nullette. Pour la validation W3C, moi j'utilise ce site : W3C Markup Validation Service. Très pratique (et très performant) pour valider facilement ses pages à partir d'une URL, d'un fichier uploadé ou d'un code directement inséré. Je me demande s'il existe d'autres outils meilleurs que celui-ci ?

C'est le problème effectivement des lois : toujours en retard d'une bonne dizaine d'année par rapport aux pratiques. On le voit notamment avec l'Arjel : ça a mis le temps, mais maintenant les sites de jeux d'argent ont un niveau minimum de sécurité à respecter, et ce niveau est même plutôt élevé (en même temps, c'est normal). Ca ne m'étonnerait pas que quelque chose d'équivalent sorte bientôt pour les sites marchands. Enfin... bientôt... dans 15/20 ans.

Ouaip, c'est ce que je dis les Scripts fournis par FB sont affreux, ils rajoutent trop de choses pour... on ne sait pas trop quoi en fait. Ah... Oui, au temps pour moi, quand tu récupères le code depuis l'appli Web FaceBook, tu as plusieurs possibilité de code : HTML5, XFBML, IFrame. En regardant ton code à l'aide de Firebug, j'ai cru que tu avais récupéré directement l'IFrame. Donc oublie ce que j'ai dit pour la mise en forme de l'IFrame... (sauf si tu décides de récupérer plutôt le code sous forme d'Iframe ). Enfin, cela ne t'empêche pas de rajouter des propriétés css à la classe ".fb_ltr" Je te conseille d'utiliser Firebug et d'étudier de près le code généré par les différents scripts pour les boutons des réseaux sociaux. Ca te permettra de voir les classes/Id des balises générées par ces scripts et de tester des mises en forme pour celles-ci grâce au panneau "Style" de Firebug. C'est pas faux, mais ça ne passe pas une validation W3C. Les balises <li> ne sont pas sensées encadrer des balises de type <div> comme celles générées par les scripts des réseaux sociaux. Bon, après, j'avoue que la validation W3C est optionnelle.

C'est vrai que cette astuce passerait très très bien. Je suis presque sûr qu'il doit dors et déjà exister des plugins JQuery qui doivent faire ça et qui permettent de spécifier un temps de défilement et ce genre de choses...

Ah oui tu as parfaitement raison... Je ne sais pas, en lisant entre les lignes de sa question, je me suis dit qu'il sous-entendait le problème d'exploitation de ces données... Mais peut-être fais-je erreur ?

Ouaip, tout ça c'est protégé par les articles 226-16 à 226-24 du code "nouveau code de procédures Pénales" dont voici les intitulés : Section 5 Des atteintes aux droits de la personne résultant des fichiers ou des traitements informatiques J'aurais bien aimé retrouver les articles complets de la rubrique "226" sur la vie privée, mais je ne retrouve plus le site gouvernemental bien conçu répertoriant tous ces articles...

Ah ouais, je connais ce soucis des liens réseaux sociaux... Le problème est que le code JavaScript fournit par LinkedIn / Facebook / Twitter, génère également de la mise en forme pour les balises nécessaires à leurs petits boutons. C'est d'ailleurs ULTRA chiant pour ceux qui veulent personnaliser ces boutons, car il faut bien le dire leur code HTML/CSS généré est vraiment moisi, je ne vois pas trop l'intérêt de toutes ces balises qui pour la plupart, ne sont même pas nécessaires (à première vue). Alors, pour résoudre ce soucis de positionnement, j'ai placé chaque bouton dans son propre <div>, le div ayant une classe ou un ID (id est toujours préférable si possible ). J'ai donc 3 divs différents contenant chacun 1 bouton. Je joue ensuite sur le CSS de ces 3 divs pour aligner les boutons. Notamment, tu as besoin de "display: inline" sur ces Divs pour qu'ils soient alignés . C'est encore plus simple s'ils sont tous les 3 placés dans un div les contenant. Mais... Comme trop de divs tuent les divs, à toi de voir si c'est vraiment nécessaire. Ensuite, j'externalise également le CSS que je peux... Ceci afin d'avoir un code HTML aussi épuré que possible tout en ayant un code CSS centralisé, toujours plus simple pour y voir plus clair et donc pour écrire les règles de mises en forme adéquate. Par exemple, l'iframe de Facebook est livré avec du CSS intégré dans l'attribut "style" de la balise "iframe". C'est moisi... et pas vraiment valide W3C. Je te conseille donc de l'externaliser en récupérant la classe : ".fb_ltr". Dans cette classe tu y mets tout ce qu'il y a déjà dans la balise iframe (en oubliant pas de le supprimer de la balise) : border: medium none; overflow: hidden; height: 20px; width: 200px; margin-bottom: 3px; Tu remarqueras que j'ai rajouté un petit "margin-bottom". Cette valeur permet d'aligner parfaitement le bouton Facebook avec les autres boutons. En espérant que tout cela saura t'aider. Je reste "à l'écoute" si jamais tu as encore des soucis. Kulgar.

A quand la possibilité de faire des PNG animés ? (ou équivalent ) Ca serait chouette quand même. Les GIF animés commencent réellement à se faire vieux...

Bonjour Lilitoxic Moi aussi je suis un petit nouveau ici et je m'y plais bien, je ne pense pas que tu auras à regretter t'être inscrite sur ce forum. En espérant bientôt échanger des messages avec toi, soit la bienvenue! Kulgar.

Ca dépend du détail de l'effet, mais on n'a rien sans rien, faire un "truc brillant passant rapidement" sur un bouton peut effectivement représenter quelques heures de travail si on veut un bon rendu. Moi je déconseille un élément Flash rien que pour un bouton, c'est contraignant, chiant à intégrer et finalement pas obligatoire. Alors juste pour un simple bouton... En revanche, il est possible de faire l'effet en Flash et de l'exporter en Gif Animé, et ça, ça reste encore la meilleure solution à mon avis pour un élément isolé d'un site comme un bouton. Un "truc" pour faire ça rapidement... Moi, là, comme ça... je vois pas. Il existe bien des sites et logiciels proposant de créer des Gifs à partir d'image gratuitement, mais évidemment 1) il faut avoir les images et 2) le rendu reste pas terrible. Après, si vraiment tu penses que ça va te consommer trop de temps, tu peux toujours rémunérer un professionnel qui ferait ça pour toi rapidement.

Ah, concernant ce soucis, je peux t'apporter ces documents : Petit tutoriel sur _AT_font-face CSS3 - Font-face Ils t'expliquent (en anglais) comment mettre une police particulière qui sera chargée par le navigateur du client. Par contre, fais attention, c'est une propriété CSS3, les anciens navigateurs ne la supportent pas forcément. Le mieux reste encore d'utiliser les "Web Safe Fonts" : liste des polices normalement supportées. Prends bien garde à vérifier la licence de la police que tu souhaites également faire télécharger par les visiteurs. En effet, bien souvent la licence autorise l'exploitation d'une police pour un Web, mais elle n'autorise pas toujours (et en fait rarement) le fait de la mettre en téléchargement sur un serveur, car c'est comme si tu la redistribuais, et pour ça il faut une licence spéciale (en général) et payante. C'est d'ailleurs pour ça que bien souvent je considère la police spéciale comme étant un petit bonus pour les visiteurs la possédant naturellement dans leur environnement.

As-tu essayé de contacter directement OVH ? Peut-être auront-ils des documentations à te fournir... Ca m'étonnerait qu'il n'ait pas déjà eu à traiter ce genre de choses pour leur client . En attendant, j'ai trouvé une petite doc sur OVH : Installer Site SSL pour HTTPS En espérant que ça t'aide Kulgar.

Article très très intéressant Ces deux passages ont retenu particulièrement mon attention : C'est bien vrai que dans la plupart des cas il y a très rarement un cahier des charges. Et quand bien même, le cahier des charges est rarement suffisamment détaillé pour donner le statut "d'auteur" au client... A ton déjà vu un client allant jusqu'à détailler la couleur de tel bouton de formulaire et l'agencement exact de tel menu dans un cahier des charges ? Sans doutes que certains clients le font (les grosses boîtes ?) mais je pense que cela reste anecdotique, le cahier des charges décrivant surtout les fonctionnalités désirées par le client. A moins qu'un WebDesigner ne soit passé par là auparavant et ait pondu une charte graphique... Mais dans ce cas l'auteur serait plutôt le WebDesigner et pas le client... Bref, très intéressant . Bon à retenir ça. Ca m'amène à la réflexion : lorsqu'on crée un site il faut faire autant attention à sa sécurité Web qu'à sa sureté juridique et à sa paternité...

Salutations Si tu veux soigner ta manie des Div, je te conseille vivement de regarder la liste des balises sur le site W3School : HTML 4 HTML 5 Cela nécessite un petit temps de recherche au départ pour trouver LA bonne balise pour chaque élément, mais tu te rends vite compte que y'a plein de balises pouvant remplacer les divs. Il faut au maximum éviter l'utilisation des Divs (j'avoue que ce n'est pas forcément évident), car comme les "span" ce sont des balises définissant une section dans un document. Une section pouvant être ... n'importe quoi, avouons-le, un Div/Span ne peut pourra jamais être aussi bien interprété par un navigateur qu'une balise définissant un type exacte d'élément (comme la balise <button> par exemple ). Moi aussi d'ailleurs il faudrait que je fasse quelques révisions sur mon site d'entreprise vis-à-vis des divs .

Bonjour ! Je suis également un petit nouveau (cf mon nombre de messages) qui s'est inscrit il y a peu, mais ça ne m'empêche pas de te souhaiter la bienvenue parmi cette nouvelle communauté !

Concernant le site Web, en fait cela dépend de ce que tu comptes faire... Soit tu comptes le refaire tout entier : changer les CSS, le menu, le maillage au sein de ton site Web, le contenu des pages... et à ce moment là, oui, je conseille soit de prendre un nouveau nom de domaine pour ne pas perdre le trafic généré par l'ancien site, soit ouvrir un sous-domaine (comme ça, tu ne payes pas 2 fois une réservation de nom de domaine). Mais attention, c'est là ce que je ferais si j'avais effectivement un site bien référencé à fort trafic que je voudrais totalement refaire. Ce n'est pas forcément LA méthode à appliquer en toutes circonstances. Soit tu comptes juste modifier en partie le contenu du site ainsi que quelques URL, dans ce cas pas la peine d'ouvrir un autre nom de domaine. Mais tu devras veiller à modifier les liens pointant vers ton site depuis d'autres sites pour ceux dont les URLs ne seront plus valides. Ca ou faire des redirections, comme expliqué sur ce sujet : Redirection 301 En tout cas... De ce que je crois comprendre, tu n'as pas travaillé le référencement en Amont dans ton site. Je ne vais pas trop me lancer dans un cours de référencement parce que je ne suis pas (encore) expert en la matière, mais je peux au moins t'aiguiller vers un blog avec lequel tu en apprendras beaucoup sur le sujet : Blog autour du référencement Notamment, lis les articles "référencement 1" à "référencement 9", je les ai moi-même lu et ils sont très bien rédigés. Bon après, tu auras sûrement d'autres questions auxquelles je serai ravi de répondre après ta lecture attentive des différents billets . Voilà, avec ça, tu devrais être armé pour travailler correctement le référencement pour la nouvelle version de ton site .

Hmm, à mon avis, il parlait des mots et expressions clés utilisés pour l'optimisation du contenu du site Web, c'est bien ça ? Donc, les mots qui déterminent le nom des hyperliens, le menu, l'architecture du site, etc. etc... Enfin, si j'ai bien compris le "je repars de 0". _AT_Blood : Et pourquoi ne pas mettre le nouveau site sur un nouveau nom de domaine ou un sous-domaine ? Dès que ton nouveau site est en ligne, tu mets, sur ton ancien site : "une nouvelle version du site existe, vous allez être redirigés" et tu renvoies vers la nouvelle version. Comme ça : 1) Ton ancien site reste référencé, 2) Tes clients qui venaient sur ton ancien site viennent sur le nouveau, 3) Ton nouveau site bénéficiera déjà du trafic normalement récupéré par ton ancien site. Comme le nom de domaine n'a plus un caractère dominant pour le référencement, cela ne devrait pas poser de soucis, si ? Enfin, en tout cas, il semble que ça soit la pratique la plus courante lorsqu'il s'agit de faire une refonte totale d'un site . Et, une fois que ton nouveau site est aussi bien référencé que l'ancien, tu peux supprimer l'ancien site. Mais attention au duplicat content si tu utilises cette méthode, vieille bien à ce que le contenu de ton ancien et nouveau site ne soit pas strictement identique.