Suport technique et veille technologique
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.
- Mai 2019 -
Un nouvel en-tête HTTP (et un nouveau
type de lien) fait son
apparition avec ce RFC :
Sunset:
sert à indiquer la date où la
ressource Web cessera probablement d'être servie. Le but est,
lorsque le webmestre sait à l'avance qu'il retirera une ressource,
de prévenir les utilisateurs.
Normalement, bien sûr, cela ne devrait pas arriver. Les
URL doivent être
stables. Mais dans certains cas, il peut y avoir une raison
légitime de retirer une ressource qui avait été publiée sur le
Web. Et, si on le sait à l'avance, c'est
plus gentil si on prévient les utilisateurs qui accèdent à cette
ressource. Donc, en pratique, ce nouvel en-tête servira peu mais
il sera utile dans des cas précis. Par exemple (ce sont les cas
cités par le RFC, personnellement, je ne les trouve pas tous pertinents) :
- Certaines ressources sont par nature temporaires. Par
exemple, une page correspondant à une commande en cours sur un
site Web de commerce en ligne. (À mon avis, il vaudrait mieux
qu'elle soit permanente, pour pouvoir accéder à des informations
même une fois la commande exécutée.)
- Lorsqu'une migration vers de nouveaux URL est envisagée
dans le futur.
- Lorsque la loi ou un réglement quelconque l'exige. Par
exemple, le RGPD, comme les lois de
protection des données personnelles qui
l'ont précédé, exige la suppression de ces données lorsque la
raison pour laquelle elles avaient été collectées n'est plus
d'actualité. Si on les détruit au bout d'un mois, on peut
annoncer cette suppression à l'avance.
- Si la ressource fait partie d'une
API, il est possible que l'API soit
remplacée par une nouvelle version et que la date de retrait de
l'ancienne soit connue à l'avance, permettant d'informer les
utilisateurs. (Notez qu'une API comprend en général plusieurs
ressources, donc plusieurs URL. L'en-tête
Sunset:
ne permet pas de traiter ce cas,
cf. section 5 du RFC, mais le type de lien
sunset
permet d'indiquer une page Web
documentant l'API et ses changements.)
Pour ces usages, ce RFC introduit
(section 3)
donc l'en-tête HTTP Sunset:
(coucher de
soleil). Il contient une seule valeur, la date et l'heure de la
suppression, au format HTTP classique de la section 7.1.1.1 du
RFC 7231. Par exemple, pour indiquer qu'une
ressource disparait à la fin de cette année (celle de parution du
RFC) :
Sunset: Tue, 31 Dec 2019 23:59:59 GMT
Et c'est tout. L'en-tête ne donne aucune information sur ce qui
arrivera après (réponse 404, 410, redirection 3xx vers une autre ressource…)
Cet en-tête figure désormais dans
le registre
IANA des en-têtes.
Notre RFC introduit, en plus de l'en-tête HTTP, un type de
lien (cf. RFC 8288), sunset
, qui peut être mis dans d'autres contextes que celui des
en-têtes HTTP, par exemple dans du HTML
(section 6 de notre RFC). Il
permet d'indiquer des détails sur la future suppression
de la ressource, à la page Web indiquée. Ainsi, en
HTML, cela donnerait :
Ce type de lien figure dans
le
registre IANA de ces types.
Le RFC ne précise pas ce que des applications comme les
navigateurs doivent faire exactement avec
cette information. C'est un choix des auteurs des
applications. Ils peuvent choisir, par exemple, d'alerter
l'utilisateur. Notez que la date indiquée n'est qu'une indication. Le serveur
Web reste libre de garder la ressource plus longtemps, ou au
contraire de la supprimer avant.
Quelques logiciels utilisent ou génèrent l'information sur le
coucher de soleil :
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)