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 2017 -
Un très court RFC discutant un problème
de procédure : dans le RFC 2119, qui décrit
les termes précis à utiliser dans les normes, un doute subsistait
sur la casse de ces termes.
Ce RFC 2119 est celui qui formalise les
fameux MUST, SHOULD et MAY, les termes qu'il faut utiliser dans
les normes pour être sûr d'indiquer le
niveau exact d'exigence. Suivant l'exemple du RFC 2119, ils sont toujours écrits en
CAPITALES pour les distinguer du sens
courant en anglais, mais cet usage n'était
pas explicite dans le RFC 2119 (qui a juste
un vague « These words are often
capitalized »). Un oubli que
corrige notre RFC 8174. Désormais, MUST n'a le sens
du RFC 2119 que s'il est en capitales.
Par exemple, dans le RFC 8120, dans le texte « The
client SHOULD try again to construct a req-KEX-C1 message in
this case », SHOULD est en capitales et a donc bien
le sens précis du RFC 2119 (le client est
censé ré-essayer de faire son message, sauf s'il a une très
bonne raison), alors que dans le texte « This case should not happen
between a correctly implemented server and client without any
active attacks », should est en
minuscules et a donc bien son sens plus informel qui est
usuel en anglais.
Le texte qu'il est recommandé d'inclure dans les RFC qui font
référence au RFC 2119 apporte désormais
cette précision : « The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119],[RFC 8174] when, and only when, they
appear in all capitals, as shown here. » Plusieurs auteurs de RFC, conscients de
l'ambiguité, avaient d'ailleurs déjà fait une telle modification
dans leur référence au RFC 2119. Ainsi, le
RFC 5724 dit « The _capitalized_ [souligné par moi] key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. »
Notez que le fait de faire une différence sémantique entre le
mot en minuscules et le mot en capitales est assez typique des
utilisateurs de l'alphabet latin, et
déroute toujours beaucoup les utilisateurs d'écritures qui n'ont
pas cette distinction, comme les Coréens.
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 (...)
