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.
- Février 2020 -
Traditionnellement, le fonctionnement de la normalisation dans
l'Internet sépare deux fonctions :
l'IETF
développe les normes techniques (qui sont publiées dans les
RFC, documents
immuables) et un opérateur de registres techniques, actuellement
l'IANA, gère les nombreux registres qui
stockent les paramètres des protocoles de l'IETF. Au contraire des
RFC, ces registres changent tout le temps. Ce nouveau RFC décrit les
principes de haut niveau sur lesquels repose le fonctionnement de
ces registres. Il remplace le RFC 7500, sans
changement crucial, juste en intégrant la nouvelle organisation
administrative de l'IETF, qui voit le remplacement de l'IAOC par
l'IETF
LLC.
Ces registres sont cruciaux pour le bon fonctionnement de
l'Internet. Presque tous les protocoles Internet dépendent d'un ou
de plusieurs registres. Aujourd'hui, il existe plus de 2 000 registres à l'IANA (la liste complète est en https://www.iana.org/protocols
). Les valeurs stockées
peuvent être des nombres, des chaînes de caractères, des adresses,
etc. Leur allocation peut être centralisée
(tout est à l'IANA) ou décentralisée, avec
l'IANA déléguant à des registres qui à leur tour délèguent, comme
c'est le cas pour les noms de
domaine et pour les adresses IP.
Notons aussi que, pendant longtemps, la gestion des registres et
la publication des RFC étaient assurés par le même homme, Jon Postel à l'ISI. Aujourd'hui, les deux opérations sont
complètement séparées, https://www.iana.org/
et https://www.rfc-editor.org/
.
L'IANA n'a pas de pouvoirs de police : le respect des registres
IANA dépend uniquement de la bonne volonté générale. Évidemment, la
pression est forte pour respecter ces registres, puisque le bon
fonctionnement de l'Internet en dépend. Ce RFC présente les
principes sur lesquels ces registres reposent (sections 2 et 3 du
RFC) :
- Unicité des identificateurs. C'est l'un des principaux buts
des registres, s'assurer que qu'il n'y a qu'un seul
.fr
ou
.org
, ou que
l'algorithme 13 de DNSSEC désigne bien ECDSA
pour tout le monde.
- Stabilité. Les registres doivent tenir plus longtemps que la
page Web corporate moyenne. Leur contenu existant
ne doit pas changer sauf s'il y a une très bonne raison.
- Prédictabilité. Le processus d'enregistrement doit être
prévisible et ne pas comporter de soudaines surprises (« finalement,
il faut tel papier en plus »). Parfois, un jugement humain est
nécessaire (cf. RFC 8126) donc le processus
n'a pas à être algorithmique, ni à être limité dans le temps, mais
il ne doit pas soudainement ajouter des étapes non prévues.
- Publicité. Les registres doivent être publics (en pratique, le
principal mode de distribution est via le Web). Ce n'est
pas si évident que cela, les dinosaures attardés de la
normalisation, comme l'AFNOR, l'ISO ou l'IEEE ne le font pas.
- Ouverture. Le processus qui détermine les politiques
d'enregistrement doit être ouvert à tous ceux qui désirent
participer. Dans presque tous les cas, c'est l'IETF qui
détermine cette politique (les exceptions sont importantes comme la
gestion de la racine
des noms de domaine), via un RFC développé en effet dans un processus ouvert. Le RFC 8126 détaille les politiques IANA
possibles. (Parmi elles, certaines nécessitent un examen par un
expert, le jugement humain mentionné plus haut.)
- Transparence. La gestion des registres ne doit pas être
opaque. On peut écrire à l'IANA, ou bien passer les voir
Away From Keyboard pendant les réunions IETF, où
l'IANA a toujours un stand.
- Redevabilité. L'IANA doit rendre compte de sa gestion. Selon
le RFC 8722, la supervision
de la fonction IANA incombe à l'IAB (RFC 2850). En outre,
l'IETF LLC
(RFC 8711) a un SLA avec l'actuel
opérateur de la fonction IANA, l'ICANN. L'IAB
et l'IETF LLC sont eux-même redevables devant une communauté plus
large, via le processus NomCom (RFC 8713). Pour les adresses IP et les ressources associées,
le RFC 7249 fait gérer la redevabilité par les
RIR (RFC 7020). Ceux-ci sont des organisations ouvertes
et eux-même redevables devant leurs membres. (Avez-vous noté quel
registre n'était pas
mentionné comme bon exemple par le RFC ?)
La section 5 décrit le changement depuis le prédécesseur, le RFC 7500. Il ne s'agit que d'un changement
bureaucratique ; l'ancienne IAOC (IETF Administrative
Oversight Committee) a été, dans le RFC 8711, remplacée par une nouvelle structure,
l'IETF LLC (Limited Liability Company),
nécessitant la mise à jour du RFC 7500.
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 (...)