Effectivement, la plus-value réalisée par les robots et spider tient du référencement, mais aussi de l'exploitation des contenus qu'ils permettent. Le contenu leur est aussi destiné.
Le concepteur de l'outil ne devrait selon moi pas avoir à pallier à (il paraît que pallier à existe d'après https://fr.wiktionary.org/wiki/pallier ) des codes déficients dont il ne peut connaître par avance quels défauts ont pu être imaginés par le développeur (c'est que ça a de l'imagination, un développeur).
Aussi les concepteurs de tels outils devraient s'attacher à tenir compte d'un standard afin d'analyser les contenus et les exploiter, standards développés précisément dans ce but, et rien que le standard. Ce qu'ils ne font heureusement pas, à lire les titres et descriptions de Google par exemple, lorsqu'ils ont peu de sens... mais sont exploités quand même, puisque même un contenu mal fichu peut être utile.
Aussi l'architecte (au sens général) de l'outil qui sert d'interface à l'utilisateur, quel qu'il soit (du GET à IExplorer, ou Weeboob...), ne devrait pas non plus se soucier des erreurs rencontrées sur les pages, et se concentrer sur les fonctionnalités de l'outil. Ce que là non plus il ne fait heureusement pas, et les navigateurs insérant des fonctions permettant de lire les contenus mal fichus ou non standards.
La description des contenus, peut être simplement de fixer ces liens internes cassés, ou pages déplacées sans redirection. Plutôt que d'imposer à l'utilisateur de chercher et l'outil de recherche de pallier. Ces concepteurs de sites ayant autant peu d'intérêt pour les références des sites externes, qu'ils ont la volonté de capter l'utilisateur, lui imposant un parcours précis pour accéder à l'information. Peut-être mal formés au concept de Toile (Web) et de réseau (network), ou le faisant volontairement pour limiter l'accès à leurs informations, ce qui devient hors-propos.
Reste la question du contenu, de l'information.
Si tout est information, tout peut être considéré comme contenu, et le contenant pouvant être lui aussi information ou simple enveloppe dépourvue d'intérêt. L'un et l'autre sont valable.
Pour cette article j'avais fixé, traitant du fond et de la forme, la limite à ce qui est effectivement statique, l'information brute.
Dès lors qu'elle est dynamique, elle n'est plus brute, et devient évanescente (contenu quantique ?). Elle n'est plus la même selon le contexte, et n'est plus une #entité.
On a alors affaire à un contenant qui vient modifier l'information brute, ou une application qui attend un paramètre pour fournir un résultat, comme « un nombre au hasard entre 1 et 6 ». Dans ce cas, l'information serait la formule, et ne fournirait pas de résultat. Le résultat deviendrait le contenu brut, dès lors qu'il serait soit fournissant le résultat statique, soit fournissant la formule, le paramètre, et son résultat.
Que le code soit effectué sur le serveur, ou sur le client n'a pas d'impact sur ce point.
On pourrait soulever le problème de la Licence libre qui impose de fournir le code, sur demande, à l'utilisateur.
Pour un logiciel libre, condition nécessaire pour que le logiciel puisse être modifié et redistribué (soit de façon libre avec ls GPL, soit de façon fermée avec BSD).
Pourtant, si ce code n'est pas exécuté sur le client, il semble que cette obligation n'est valable que pour le déploiement de l'applicatif sur un serveur, aussi il ne devrait concerner que les codes compilés, puisque les codes interprétés sont en clair sur le serveur, c'est à dire la diffusion du code source au bénéficiaire de la redistribution.
[^] # Re: KISS : faire simple, faire accessible
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -1.
Effectivement, la plus-value réalisée par les robots et spider tient du référencement, mais aussi de l'exploitation des contenus qu'ils permettent. Le contenu leur est aussi destiné.
Le concepteur de l'outil ne devrait selon moi pas avoir à pallier à (il paraît que pallier à existe d'après https://fr.wiktionary.org/wiki/pallier ) des codes déficients dont il ne peut connaître par avance quels défauts ont pu être imaginés par le développeur (c'est que ça a de l'imagination, un développeur).
Aussi les concepteurs de tels outils devraient s'attacher à tenir compte d'un standard afin d'analyser les contenus et les exploiter, standards développés précisément dans ce but, et rien que le standard. Ce qu'ils ne font heureusement pas, à lire les titres et descriptions de Google par exemple, lorsqu'ils ont peu de sens... mais sont exploités quand même, puisque même un contenu mal fichu peut être utile.
Aussi l'architecte (au sens général) de l'outil qui sert d'interface à l'utilisateur, quel qu'il soit (du GET à IExplorer, ou Weeboob...), ne devrait pas non plus se soucier des erreurs rencontrées sur les pages, et se concentrer sur les fonctionnalités de l'outil. Ce que là non plus il ne fait heureusement pas, et les navigateurs insérant des fonctions permettant de lire les contenus mal fichus ou non standards.
La description des contenus, peut être simplement de fixer ces liens internes cassés, ou pages déplacées sans redirection. Plutôt que d'imposer à l'utilisateur de chercher et l'outil de recherche de pallier. Ces concepteurs de sites ayant autant peu d'intérêt pour les références des sites externes, qu'ils ont la volonté de capter l'utilisateur, lui imposant un parcours précis pour accéder à l'information. Peut-être mal formés au concept de Toile (Web) et de réseau (network), ou le faisant volontairement pour limiter l'accès à leurs informations, ce qui devient hors-propos.
Reste la question du contenu, de l'information.
Si tout est information, tout peut être considéré comme contenu, et le contenant pouvant être lui aussi information ou simple enveloppe dépourvue d'intérêt. L'un et l'autre sont valable.
Pour cette article j'avais fixé, traitant du fond et de la forme, la limite à ce qui est effectivement statique, l'information brute.
Dès lors qu'elle est dynamique, elle n'est plus brute, et devient évanescente (contenu quantique ?). Elle n'est plus la même selon le contexte, et n'est plus une #entité.
On a alors affaire à un contenant qui vient modifier l'information brute, ou une application qui attend un paramètre pour fournir un résultat, comme « un nombre au hasard entre 1 et 6 ». Dans ce cas, l'information serait la formule, et ne fournirait pas de résultat. Le résultat deviendrait le contenu brut, dès lors qu'il serait soit fournissant le résultat statique, soit fournissant la formule, le paramètre, et son résultat.
Que le code soit effectué sur le serveur, ou sur le client n'a pas d'impact sur ce point.
On pourrait soulever le problème de la Licence libre qui impose de fournir le code, sur demande, à l'utilisateur.
Pour un logiciel libre, condition nécessaire pour que le logiciel puisse être modifié et redistribué (soit de façon libre avec ls GPL, soit de façon fermée avec BSD).
Pourtant, si ce code n'est pas exécuté sur le client, il semble que cette obligation n'est valable que pour le déploiement de l'applicatif sur un serveur, aussi il ne devrait concerner que les codes compilés, puisque les codes interprétés sont en clair sur le serveur, c'est à dire la diffusion du code source au bénéficiaire de la redistribution.
Les termes employés peuvent être inexacts ou approximatifs, tout comme les raisonnements et conclusions, n'étant, je le rappelle, pas un spécialiste.
Le maître d'oeuvre, concepteur du site ou développeur au sens large : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'%C5%93uvre
Le client au sens commercial, appelé ici bénéficiaire : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'ouvrage