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 -
Ce nouveau RFC
étend le format de fichiers CBOR (normalisé dans le RFC 7049) pour représenter des tableaux de données numériques,
et des tableaux multidimensionnels.
Le format CBOR est en effet
extensible par des étiquettes
(tags) numériques qui indiquent le type de la
donnée qui suit. Aux étiquettes définies dans la norme originale, le
RFC 7049, ce nouveau RFC ajoute donc des étiquettes pour des
types de tableaux plus avancés, en plus du type tableau de base de
CBOR (qui a le type majeur 4, cf. RFC 7049, et
dont les données ne sont pas forcément toutes de même type).
Le type de données « tableau de données numériques » est utile
pour les calculs sur de grandes quantités de données numériques, et
bénéficie de mises en œuvres adaptées puisque, opérant sur des
données de même type, contrairement aux tableaux CBOR classiques, on
peut optimiser la lecture des données. Pour comprendre l'utilité de
ce type, on peut lire « TypedArray
Objects » (la spécification de ces tableaux dans la
norme ECMA de
JavaScript, langage dont CBOR reprend le
modèle de données) et « JavaScript
typed arrays » (la mise en œuvre dans Firefox).
La section 2 spécifie ce type de tableaux dans CBOR. Un tableau
typé (typed array) est composé de données
numériques de même type. La représentation des nombres (par exemple
entiers ou
flottants) est
indiquée par l'étiquette. En effet, il n'y a pas de représentation
canonique des nombres dans un tableau typé (contrairement aux types
numériques de CBOR, types majeurs 0, 1 et 7) puisque le but de ces
tableaux est de permettre la lecture et l'écriture rapides de
grandes quantités de données. En stockant les données sous diverses
formes, on permet de se passer d'opérations de conversion.
Il n'y a pas moins de 24 étiquettes (désormais enregistrées dans
le
registre IANA des étiquettes CBOR) pour représenter toutes
les possibilités. (Ce nombre important, les étiquettes étant codées
en général sur un seul octet, a suscité des discussions dans le
groupe de travail, mais se justifie par le caractère très courant de
ces tableaux numériques. Voir la section 4 du RFC.) Par exemple,
l'étiquette 64 désigne un tableau typé d'octets (uint8
),
l'étiquette 70 un tableau typé d'entiers de 32 bits non
signés et petit-boutiens
(uint32
), l'étiquette 82 un tableau typé de
flottants IEEE 754 de 64 bits
gros-boutiens, etc. (CBOR est normalement gros-boutien, comme tous
les protocoles et formats Internet, cf. section 4 du RFC.) Les
étiquettes ne sont pas attribuées arbitrairement, chaque nombre
utilisé comme étiquette encode les différents choix possibles dans
les bits qui le composent. Par exemple, le quatrième bit de
l'étiquette indique si les nombres sont des entiers ou bien des
flottants (cf. section 2.1 du RFC pour les détails).
Le tableau typé est ensuite représenté par une simple chaîne
d'octets CBOR (byte string, type majeur 2). Une
mise en œuvre générique de CBOR peut ne pas connaitre ces nouvelles
étiquettes, et considérera donc le tableau typé comme une bête suite
d'octets.
La section 3 de notre RFC décrit ensuite les autres types de
tableaux avancés. D'abord, les tableaux multidimensionnels (section
3.1). Ils sont représentés par un tableau qui contient deux tableaux
unidimensionnels. Le premier indique les tailles des différentes
dimensions du tableau multidimensionnel, le second contient les
données. Deux étiquettes, 40 et 1040, sont réservées, pour
différencier les tableaux en ligne d'abord ou en colonne
d'abord. Par exemple, un tableau de deux lignes et trois
colonnes, stocké en ligne d'abord, sera représenté par deux tableaux
unidimensionnels, le premier comportant deux valeurs, 2 et 3, le
second comportant les six valeurs, d'abord la première ligne, puis
la seconde.
Les autres tableaux sont les tableaux homogènes (étiquette 41),
en section 3.2. C'est le tableau unidimensionnel classique de CBOR,
excepté que tous ses élements sont du même type, ce qui peut être
pratique au décodage, pour les langages fortement typés. Mais attention : comme rappelé
par la section 7 du RFC, consacrée à la sécurité, le décodeur doit
être prudent avec des données inconnues, elles ont pu être produites
par un programme malveillant ou bogué, et donc non conformes à la
promesse d'homogénéité du tableau.
La section 5 de notre RFC donne les valeurs des nouvelles
étiquettes dans le langage de schéma CDDL (RFC 8610).
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 (...)