Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Le Web, ce sont les pages auxquelles on
accède depuis son navigateur, avec les
textes à lire et les images à regarder. Mais ce sont aussi de
nombreuses applications, avec une API,
prévues pour être utilisées depuis un programme spécifique, pas
depuis le navigateur Web. Ces Web services ont
un ou plusieurs URL pour les appeler, et
des ressources supplémentaires comme la documentation. Ce nouveau
RFC décrit un type de liens hypertextes
permettant de trouver l'URL de la documentation d'un service.
Normalement, on peut interagir avec un service Web sans
connaitre les détails à l'avance. La négociation de contenu, par
exemple (RFC 7231, sections 3.4 et 5.3) permet de choisir
dynamiquement le type de
données. En combinant les outils de
l'architecture Web (URI,
HTTP, etc), on peut créer des services plus
simples que les anciennes méthodes compliquées, type
CORBA. (Le terme de service REST est souvent utilisé pour ces
services modernes et simples.) Mais cela ne dispense pas complètement de documentation
et de description des services. (La documentation est du texte
libre, conçue pour les humains, la description est sous un format
structuré, et conçue pour les programmes.) Il faut donc, pour
accéder à un service, trouver documentation et description. C'est
ce que propose ce RFC, avec de nouveaux
types de liens (les types de liens sont décrits dans le RFC 8288).
Notez bien que ce RFC ne dit pas comment doit être écrite la
documentation, ou sous quel format structurer la description. Un
format de description courant aujourd'hui est
OpenAPI, fondé sur
JSON. Mais il en existe d'autres comme
RAML (fondé sur
YAML) ou RSDL, si
vous avez des expériences concrètes sur ces langages, ou des
opinions sur leurs avantages et inconvénients, je suis
intéressé. (Dans le passé, on utilisait parfois
WSDL). Ce RFC fournit juste un moyen de
trouver ces descriptions. (En prime, il permet également de
trouver l'URL d'un service décrivant l'état actuel d'un service,
permettant d'informer, par exemple, sur des pannes ou sur des
opérations de maintenance.)
Parfois, documentation et description sont fusionnées en un
seul ensemble de ressources. Dans ce cas, on n'est pas obligé
d'utiliser notre RFC, on peut se contenter du type de lien décrit
dans le RFC 5023.
Les quatre nouveaux types de liens (section 4 du RFC) sont :
service-doc pour indiquer où se
trouve la documentation (écrite pour des
humains),service-desc pour donner accès à la
description (conçue pour des
programmes),service-meta pour
l'URI des
méta-informations diverses sur le service, comme des
informations à caractère juridique (politique « vie privée » du
service, par exemple),status pour l'état actuel du service.
Ces types sont notés dans
le
registre IANA des types de liens (section 6 du RFC).
Un exemple dans un document HTML serait,
pour indiquer la documentation :
Et dans les en-têtes HTTP, ici pour indiquer la description :
Link: rel="service-desc";
type="application/json"
Si vous voulez voir un exemple réel, il y en a un dans le
DNS Looking Glass. Les
en-têtes HTTP, et le code HTML contiennent un lien vers la
documentation.
La section 5 est consacrée à
status, qui permet d'indiquer une ressource
sur le Web donnant des informations sur l'état du
service. On peut voir par exemple la page de Github ou
bien celle de
CloudFlare. (Évidemment, il est recommandé qu'elle soit hébergée sur
une infrastructure différente de celle du service dont elle
indique l'état de santé, pour éviter que le même problème
DNS, BGP ou autre ne
plante le service et son bulletin de santé en même temps. C'est ce
que ne fait pas la page
de Framasoft, qui utilise le même nom de domaine.) Aucune obligation sur le contenu
auquel mène le lien, cela peut être un texte conçu pour un humain
ou pour un programme.
Quelques considérations de sécurité pour finir (section 7 du
RFC). D'abord, toute documentation peut être utilisée par les
gentils utilisateurs, mais aussi par les méchants attaquants. Il
peut donc être prudent de ne donner dans la documentation que ce
qui est nécessaire à l'utilisation du service. D'autre part, la description (ce
qui est en langage formel, analysable par un programme) peut
permettre davantage d'automatisation. C'est bien son but, mais cela
peut aider les attaquants à automatiser les attaques. Sans même
parler d'attaque délibérée, le RFC note aussi que cette
automatisation, utilisée par un programme client mal écrit, peut
mener à une charge importante du service si, par exemple, le
client se met à utiliser sans limitation toutes les options qu'il découvre.
Enfin, tout programmeur et toute programmeuse sait bien que les
documentations ne sont pas toujours correctes. (Ou, plus
charitablement, qu'elles ne sont pas toujours à jour.) Le
programme client ne doit donc pas faire une confiance aveugle à la
documentation ou à la description et doit se préparer à des
comportements imprévus de la part du service.
À part le DNS Looking Glass, je n'ai pas encore trouvé de service Web qui utilise ces types
de liens. Si vous en voyez un, vous me prévenez ?
