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 -
Le passage de la structure administrative de l'IETF vers « IASA
2.0 » (IASA = IETF Administrative Support
Activity, cf. RFC 8711) a
nécessité des changements dans la manière dont les membres de
l'IETF
Trust sont désignés. Ces changements sont décrits
dans le RFC 8714, et expliqués
brièvement dans ce court RFC.
Petit rappel : l'IETF Trust gère la
propriété intellectuelle de l'IETF, comme la
marque ou comme le nom de domaine ietf.org et, bien sûr, comme les RFC, dont la licence dépend
formellement de cet IETF Trust. Cet IETF
Trust est enregistré
aux États-Unis. Au début, les membres de l'IAOC (IETF
Administrative Oversight Committee) étaient également
membres de l'IETF Trust. L'IAOC ayant été
supprimé par le RFC 8711, il fallait
donc changer les règles de désignation, ce qu'a fait le RFC 8714.
Lors des discussions sur la création de l'« IASA 2 »
(IETF Administrative Support Activity, deuxième
version), il avait été envisagé de fusionner l'IETF
Trust avec la nouvelle structure, l'IETF LLC. Finalement,
l'IETF Trust reste une organisation
indépendante. Les raisons ? D'abord, une volonté de minimiser les
changements liés au projet « IASA 2 », ensuite, l'observation du
fait que le travail de l'IETF Trust est assez
différent de celui de la IETF LLC (décrite dans le RFC 8711). L'IETF Trust a une
activité calme, avec peu ou pas de problèmes urgents à résoudre, et
les changements sont rares.
Mais comme il fallait bien tenir compte de la disparition de
l'IAOC, le choix a été de réduire la taille de l'IETF
Trust, plutôt que de créer un mécanisme alternatif à
l'IAOC (puisque, comme indiqué plus haut, l'IETF
Trust ne demande pas beaucoup de travail). Les cinq
membres sont désignés par le comité de nomination de l'IETF (« NomCom »), par
l'IESG et par l'ISOC. Pour ce dernier cas, le RFC note qu'on
aurait pu utiliser l'IETF LLC et pas l'ISOC, mais que l'ISOC
semblait plus adaptée, pour une tâche qui est assez politique
(l'IETF LLC est normalement purement administrative).
Sinon, vous pouvez voir
ici un appel à candidatures du NomCom pour l'IETF
Trust.
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 (...)
