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 -
Si vous n'aimez pas les RFC de procédure, et que vous ne voulez que de
la technique, rassurez-vous, ce document est court : il spécifie le
rôle et les qualités de l'ISE (Independent Submission
Editor), celui (ou celle) qui supervise les RFC qui ne
passent pas par l'IETF. Il remplace le RFC 6548, remplacement nécessaire compte tenu de la
nouvelle structure adminstrative de l'IETF, introduite par le RFC 8711.
Comment, ça existe, des RFC non-IETF ? Tous les RFC ne naissent
pas au sein d'un des nombreux groupes de travail de l'IETF ? Eh oui,
c'est souvent oublié, mais c'est le cas, il existe une
voie indépendante qui permet à des individus de
publier un RFC, quel que soit l'avis de l'IETF. Cette voie est
décrite dans le RFC 4846. Autrefois, il
n'existait qu'un seul RFC Editor pour examiner et préparer tous les
RFC. Mais cette tâche est désormais répartie entre plusieurs
éditeurs spécialisés et l'ISE est en charge de la voie
indépendante.
Ce mécanisme de répartition des tâches pour les RFC est décrit
dans le RFC 8728 (modèle du RFC Editor,
« v2 ») et ce RFC 8730.
La section 2.1 décrit les qualifications attendues de l'ISE. Ce
doit être quelqu'un d'expérimenté (senior),
compétent techniquement dans les sujets traités à l'IETF (ce qui
fait beaucoup !), connu et reconnu de la communauté IETF, sachant
écrire et corriger, connaissant très bien
l'anglais, et capable de travailler dans le
milieu souvent agité de l'IETF.
Sa tâche principale (section 2.2) est de maintenir la qualité des
RFC de la voie indépendante, par la relecture et l'approbation des
documents, avant transmission au Producteur des RFC (RFC
Production Center). Mais il doit aussi traiter les errata
pour les RFC de la voie indépendante, contribuer à définir les
évolutions de cette voie, interagir avec les autres acteurs des RFC,
et fournir des statistiques à l'IAB et l'IETF LLC (cf. RFC 8711). Il peut se faire assister par un conseil
consultatif, dont il nomme les membres « at the pleasure of
the ISE », dit le RFC dans une jolie formule. Il y a aussi
un conseil éditorial, également nommé par l'ISE (section 3 du
RFC).
Le site officiel des RFC contient une page
consacrée à la voie indépendante, si cela vous tente d'y
publier.
L'ISE est nommé par l'IAB. Aujourd'hui, c'est Adrian Farrel, qui joue ce
rôle.
Il y a peu de changements depuis le RFC précédent, le RFC 6548, essentiellement le remplacement de
l'ancienne structure administrative de l'IETF (l'IAOC) par la
nouvelle (l'IETF LLC).
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 (...)
