Un projet formel sur la légalisation du partage des oeuvres numériques associée à une rémunération des artistes inspirée des propositions de R.Stallman arriverait en février.

Le programme officiel d'EELV a aussi été publié le 22 décembre. On peut y lire :

Les écologistes s'engagent à :
Promouvoir le partage des biens communs et la protection des droits des internautes, en abandonnant les politiques répressives et sécuritaires de type DADVSI, HADOPI ou ACTA et en encourageant l'utilisation des logiciels libres et l’emploi des formats ouverts, en inscrivant dans la loi la neutralité du net.

Il faut par ailleurs développer l'accès libre aux biens publics par la numérisation du patrimoine et la mise en place d’exceptions aux droits de propriété intellectuelle tenant compte de l’intérêt général.

Un WHOIS sur le nom de domaine canonical.com confirme cela :

Registrant:
James Troup
Canonical, Ltd.
One Circular Road
Douglas Isle of Man IM1 1AF
GB
hostmaster@canonical.com
+44.1624643643
Fax: -

Cela prose de graves problèmes de sécurité car une application malveillante peut récupérer de nombreuses informations confidentielles dont :

• le mot de passe root lorsque sa demande est effectuée lors d'un "su" dans un terminal graphique ou dans un popup.
• les mots de passe demandées par toutes les applications graphiques (clé GPG, navigateur web...)
• les données que vous souhaiteriez transmettre de manière confidentielles (n° de carte bancaire dans une page web, rédaction d'un email professionnel, etc...)

Il semblerait même possible defaire des captures d'écran (Ex: Pykeylogger).

Bref, une application ayant accès au serveur graphique peut écouter tout ce que tape l'utilisateur et ce qu'il voit sur son écran, et ce sans nécessiter de droits root.

La plupart d'entre nous sont conscients que les applications lancées par l'utilisateur ont en principe accès à toutes nos données personnelles (/home/user) et un accès réseau complet (d'où les firewalls applicatifs sous Windows pour contrôler un peu mieux cela).

Les gestionnaires de fenêtres des applications nous font croire que les applications sont isolées (plusieurs fenêtres qui ne semblent pas communiquer entre elles, gestion du focus de l'application "active", étant la seule avec laquelle on peut interagir, popup sur écran grisé lors de la demande du password root faisant penser un un mode sécurisé) alors qu'il n'en est rien.

Il semble donc que la sécurité sous linux avec le serveur graphique X suppose que l'utilisateur ne lance pas par lui-même de logiciel malveillant (spyware, malware). Dans le cas contraire, il semble aisé de devenir root et de compromettre l'installation dans les cas où l'utilisateur se sert de son interface graphique pour gérer son ordinateur (gestionnaires d'applications Synaptic et mises à jours par exemple), ce qui est le cas dans la majorité des utilisations GNU/Linux en tant que bureau personnel.

Cela suppose-t-il de n'utiliser que des applications open-sources ? Ce n'est malheureusement pas le cas général et que penser de la vague d' "applis web" qui a accès à de plus en plus de fonctionnalités sur l'ordinateur de l'utilisateur?

Apple semble prendre le problème de la sécurité entre applications au sérieux et vient d'annoncer que les applications distribuées par le Mac App Store seront "sandboxées" ou isolées de manière assez fortes les unes des autres (accès aux fichiers, réseau ainsi qu'aux autres applications par une API contrôlée). Cela impose néanmoins de fortes contraintes d'usage...

Wayland, qui semble être prédestiné à remplacer X, apporte-t-il une réponse à cette problématique ?

Cette version apporte notamment le support attendu des blockbusters de l'année que sont les Samsung Galaxy S et Galaxy S2.

La particularité de Cyanogen sur les autres rom Android est son modèle de développement communautaire et ouvert que l'on retrouve dans la plupart distributions GNU/Linux. Ainsi le code source de Cyanogen est libre hormis les drivers propriétaires nécessaires pour faire fonctionner divers matériels comme l'explique R.Stallman.

J'ai utilisé la version de développement pendant 2 mois sur mon Galaxy S et la vitesse de l'interface est sans commune mesure avec la rom officielle de Samsung qui souffre de lags intempestifs. Son seul défaut est sûrement de se focaliser uniquement sur la recherche de pureté applicative en conservant l'ergonomie d'Android vanilla sans surcouche qui n'est pas très réussie il faut l'avouer.

Celle-ci comprend un noyau Linux mis à jour contenant des corrections de bogues de la suite Linux "à long terme" jusqu’à la version 2.6.32.46, des pilotes mis à jour pour gérer les nouvelles puces gigabit Ethernet de Broadcom, Intel et Realtek, ainsi que diverses corrections de sécurité dans de nombreux paquets.

Je vous invite à consulter l'annonce de publication officielle pour plus de détails et une bonne mise à jour !

Cet article est la traduction de la tribune de Richard Stallman parue dans le journal anglais the Guardian : "Is Android really free?".

Edit : Suite au commentaire de Slystone sur le droit de publier une traduction de cet article, j'ai remplacé ma traduction de l'article par celle approuvée par la FSF afin de respecter la licence  CC-BY-ND de l'article original.

par Richard Stallman
Publié initialement dans The Guardian
Copyright © 2011 Richard Stallman
licence  CC-BY-ND

Dans quelle mesure est-ce qu'Android respecte les libertés de ses utilisateurs ? Pour l'utilisateur d'un ordinateur qui chérit la liberté, c'est la question la plus importante à se poser pour tout logiciel.

Dans le mouvement du logiciel libre, nous concevons des logiciels qui respectent les libertés des utilisateurs de sorte que vous comme moi puissiez échapper à l'emprise de ceux qui les dénient. Cela contraste avec l'idée de l'« open source » qui se concentre sur la façon de concevoir le code ; c'est une réflexion différente qui s'intéresse principalement à la qualité du code plutôt qu'à la liberté. Ainsi, le souci principal n'est pas de savoir si Android est « ouvert », mais s'il permet à celui qui l'utilise d'être libre.

Android est un système d'exploitation orienté principalement vers les téléphones portables. Il est constitué du noyau Linux (le noyau de Torvalds), quelques bibliothèques, une plateforme Java, et quelques applications. Sans parler de Linux, le logiciel d'Android versions 1 et 2 a été concu essentiellement par Google. Google l'a sorti sous la licence Apache 2.0, qui est une licence libre permissive sans copyleft.

La version de Linux incluse dans Android n'est pas un logiciel entièrement libre puisque qu'il contient des morceaux de code propriétaire (des « binary blobs »), tout comme la version de Torvalds de Linux, dont quelques-uns sont réellement utilisés dans des machines tournant sous Android. Les plateformes Android utilisent des microprogrammes propriétaires aussi, ainsi que des bibliothèques propriétaires. À part cela, le code source des versions 1 et 2 d'Android telles que faites par Google sont libres, mais ce code est insuffisant pour faire tourner l'appareil. Quelques applications qui viennent généralement avec Android sont propriétaires aussi.

Android est très différent du système d'exploitation GNU/Linux, car il contient très peu de GNU. En effet, le seul élément commun entre Android et GNU/Linux se résume à peu près à Linux, le noyau. Les gens qui font l'erreur de croire que « Linux » fait référence à la totalité de l'écosystème GNU/Linux s'emmêlent les pinceaux, et font des affirmations paradoxales telles que « Android contient Linux, mais ce n'est pas Linux ». Si nous évitons cette confusion au départ, la situation est simple : Android contient Linux, mais pas GNU. Ainsi Android et GNU/Linux sont majoritairement différents.

À l'intérieur d'Android, le noyau Linux reste un programme séparé, avec le code source sous licence GNU GPL version 2. Combiner Linux avec le code sous licence Apache 2.0 représenterait une violation du copyright, puisque les licences GPL version 2.0 et Apache 2.0 sont incompatibles. Les rumeurs que Google a d'une manière ou d'une autre fait passer Linux sous licence Apache sont fausses. Google n'a aucun pouvoir pour changer la licence du code de Linux, et n'a pas essayé de le faire. Si les auteurs de Linux autorisaient son usage sous la version 3 de la licence GPL, ensuite ce code pourrait être combiné avec un code sous licence Apache, et la combinaison pourrait être rendue publique sous licence GPL version 3. Mais Linux n'a pas été publié ainsi.

Google a respecté les règles de la licence GPL (General Public License ou Licence publique générale) pour Linux, mais la licence Apache sur le reste d'Android n'oblige pas à montrer le code. Google a dit qu'ils n'allaient jamais publier le code d'Android 3.0 (à part Linux), même si les exécutables ont été rendus disponibles pour le public. Le code source d'Android 3.1 est aussi retenu. Ainsi, Android 3, en dehors de Linux, est du logiciel propriétaire purement et simplement.

Google a dit qu'ils gardaient le code source de la version 3.0 parce qu'il était bogué, et que les gens devraient attendre la version d'après. Cela pourrait être un bon conseil pour ceux qui veulent juste faire tourner le système Android, mais les utilisateurs devraient être ceux qui prennent ces décisions. Et de toutes façons les développeurs et les bidouilleurs qui voudraient inclure des changements dans leurs propres versions pourraient très bien utiliser ce code.

Le fait de ne pas rendre publique deux versions du code source est source d'inquiétudes dans le sens que Google pourrait vouloir rendre Android propriétaire de manière permanente, que la publication de quelques versions d'Android ait été une stratégie temporaire afin d'obtenir l'aide de la communauté pour améliorer un logiciel propriétaire. Espérons que ce n'est pas le cas.

Dans tous les cas, la plupart du code source de plusieurs versions d'Android ont été publiées en tant que logiciel libre. Est-ce que ça veut dire que des machines qui utilisent ces versions d'Android respectent les libertés de l'utilisateur ? Non, ce n'est pas le cas pour plusieurs raisons.

Tout d'abord, la majorité des versions comprend des applications propriétaires de Google pour communiquer avec des services tels que Youtube et Google Maps. Celles-ci ne font pas officiellement partie d'Android, mais cela n'en fait pas un bon produit pour autant. Il y a aussi la présence de bibliothèques propriétaires. Qu'elles fassent partie d'Android ou pas est discutable, ce qui importe c'est que beaucoup de fonctionnalités en dépendent.

Même les exécutables qui font officiellement partie d'Android peuvent ne pas correspondre au code des versions de Google. Les constructeurs peuvent changer le code, et bien souvent ils ne publient pas le code source de leurs versions. La licence GNU GPL les oblige à redistribuer le code des versions de Linux, s'ils y consentent. Le reste du code sous licence Apache ne les oblige pas à publier le code source des versions qu'ils utilisent réellement.

Replicant, une version libre d'Android qui n'est compatible qu'avec quelques modèles de téléphones, a remplacé beaucoup de bibliothèques, et vous pouvez fonctionner sans les applications propriétaires. Mais il y a d'autres problèmes.

Des modèles sont conçus pour empêcher leur propriétaire d'installer et de modifier le logiciel. Dans cette situation, les exécutables ne sont pas libres, même s'ils sont faits à partir d'une source libre qui est disponible pour vous. Cependant, des appareils Android peuvent être « rootés » afin d'y installer un autre système d'exploitation.

Les micrologiciels importants et les pilotes sont généralement propriétaires aussi. Ceux-ci gèrent le matériel pour le réseau, la radio, le wifi, le bluetooth, le GPS, l'accélération 3D, l'appareil photo, les hauts-parleurs, et dans certains cas le microphone aussi. Sur certains modèles, quelques-uns de ces pilotes sont libres, et pour certains on peut s'en passer, mais le microphone et l'accès au réseau sont plutôt indispensables.

Le micrologiciel qui gère l'accès au réseau est préinstallé. Si tout ce que le programme se contentait de faire était de tourner dans son coin, on pourrait le considèrer comme un simple circuit. Quand on insiste sur le fait qu'un logiciel dans un ordinateur doit être libre, on peut passer sur un micrologiciel préinstallé qui ne sera jamais mis à jour, car cela ne fait pas de différence pour l'utilisateur que c'est un programme plutôt qu'un circuit.

Malheureusement, dans ce cas ce serait un circuit malveillant. Des fonctions malveillantes sont inacceptables, quelle que soit la manière dont elles sont implémentées.

Sur la plupart des téléphones Android, ce micrologiciel a tellement de contrôle qu'il pourrait transformer le produit en un appareil d'écoute. Sur certains, il peut prendre le contrôle entier de l'ordinateur principal, à travers la mémoire partagée, et peut ainsi supplanter ou remplacer le logiciel libre que vous avez installé. Avec certains modèles, il est possible d'exercer un contrôle à distance sur ce micrologiciel, et ainsi sur le téléphone tout entier, à travers le logiciel permettant l'accès au réseau. Le principe du logiciel libre, c'est d'avoir le contrôle sur la machine, et cet appareil en l'occurence ne remplit pas cette mission. Bien que n'importe quel système informatique puisse avoir des bogues, ces appareils peuvent peuvent être des bogues. (Craig Murray, dans Meurtre à Samarkand, fait le récit de son rôle dans une opération de renseignement qui convertit un téléphone portable sans Android d'une cible peu suspicieuse en un appareil d'écoute.)

En tout cas, le micrologiciel du téléphone permettant l'accès au réseau n'est pas l'équivalent d'un circuit, car le matériel permet l'installation de nouvelles versions, et il fonctionne dans ce but d'ailleurs. Puisque c'est un micrologiciel propriétaire, en pratique seul le fabricant peut faire de nouvelles versions, les utilisateurs ne le peuvent pas.

Pour résumer, on peut tolérer des versions propriétaires des micrologiciels gérant l'accès au réseau à la condition que des mises à jour ne seront pas téléchargées, elles ne prendront ainsi pas contrôle de l'ordinateur principal, et il peut seulement communiquer quand et si le système d'exploitation libre le permet. En d'autres termes, il doit avoir un fonctionnement équivalent à un circuit, et ce circuit ne doit pas être malveillant. Il n'y a pas d'obstacles à construire un téléphone Android qui a ces caractéristiques, mais nous n'en connaissons aucun.

De récentes couvertures médiatiques se sont intéressées aux guerres de brevets. Pendant les 20 ans de campagne qui ont été consacrés à l'abolition des brevets logiciels, nous avons prévenu que de telles guerres pouvaient arriver. Les brevets logiciels pourraient contraindre à la disparition de fonctions dans Android, ou même le rendre indisponible (consultez endsoftpatents.org pour plus d'informations sur les raisons nécessitant l'abolition des brevets logiciels).

Pourtant, les attaques sur les brevets, et les réponses de Google, n'ont pas de lien direct avec le sujet de cet article : comment les produits Android sont proches d'un système de distribution éthique, et comment ils échouent de peu. Ce problème mérite l'attention de la presse aussi.

Android représente une étape majeure vers un téléphone portable libre qui soit contrôlé par l'utilisateur, mais il y a encore beaucoup de chemin à parcourir. Les hackers travaillent sur Replicant, mais c'est un gros travail de rendre un nouveau modèle compatible, et il reste encore le problème du micrologiciel. Même si les téléphones Android d'aujourd'hui sont considérablement moins mauvais que les smartphones d'Apple ou de Windows, on ne peut pas dire qu'ils respectent vos libertés.

Source. Traducteur : Slystone

 
#! /usr/bin/python
# -*- coding: utf-8 -*-
 
a = [1 , 2 , 3]
"""la variable est définie dans l'espace de nom du module/script.
C'est une variale globale."""
 
def lecture_et_modification() :
    print "a:", a
    """retourne: 'a: [1, 2, 3, 4]'
    Nous sommes dans une fonction et nous voulons afficher la variable "a".
    Puisque la variable n'est pas été définie préalablement dans l'espace de nom
    de la fonction, c'est la variable globale qui est affichée."""
 
    a.append(4)
    a[0] = "hoho"
    """On peut modifier une variable globale directement.
    Comme la variable "a" n'est pas définie dans l'espace de nom de la fonction,
    c'est la variable globale est est modifiée"""
 
lecture_et_modification()
print "a:", a
"""retourne: 'a: ['hoho', 2, 3, 4]'"""
 
def creation() :
    global a
    """Cette ligne indique que la référence au nom de variable "a" doit se faire
    dans l'espace de nom global du script/module et non de la fonction"""
 
    a = 5
    """Ici, on ne modifie plus mais on crée ou re-crée la variable
    Que la variable "a" existe préalablement ou pas ne change rien.
    Si on n'écrit pas la ligne au dessus ("global a"), la variable "a"
    sera une variable locale de la fonction,
    ce qui n'est pas le comportement désiré ici."""
 
    a += 5
    """Cette syntaxe pourrait à priori faire penser à une modification
    mais il s'agit en fait du raccourci pour 'a = a + 5'.
    Il s'agit donc là là aussi d'une création de variable. Il faut donc
    préalablement déclarer "global a" si on veut que la variable soit créée
    dans l'espace global de noms"""
 
creation()
print "a:", a
"retourne 'a: 10'"""
 

La réponse en image lorsque l'on veut se servir de son smartphone pour accéder au site de musique en ligne Grooveshark.

Voila ce qui arrive lorsque l'on se rend compte d'Apple décide de ce qu'on doit manger. Android permet d'ajouter des logiciels téléchargés en dehors du market et encore mieux d'installer sa propre distribution opensource type Cyanogen afin d'avoir enfin the powwwwwwwwwwer !

Facebook, et Google encore plus, ont un modèle économique basé sur la collecte et la revente des infos personnelles des gens. Ne comptez donc pas sur eux pour résoudre le problème.

En face, on a :

• des copies en version serveur : Diaspora, Jappix, Movim, etc...
• de copies décentralisées : Peerscape
• des logiciels de P2P : Retroshare

Aucune de ces solutions ne semble émerger car elles disposent d'handicaps techniques.

Le problème des versions avec serveur, c'est qu'il faut un geek dans l'histoire qui gère le serveur et dispose dispose d'un pc allumé 24/24. De plus, de part sa position centrale, il a accès aux données de tous les utilisateurs de son service. (Cette critique est aussi valable pour le réseau de messagerie Jabber)

Le problème des versions P2P, c'est que lorsque l'on est déconnecté, nos amis ne peuvent plus nous joindre, ni laisser de message. Il y a bien l'astuce de faire de stocker une copie de nos données chez nos amis pour espérer toujours avoir une copie en ligne, mais c'est une hypothèse purement statistique. Comment retrouver ses amis si chacun change d'ip à tour de bras (maison, smartphone, bureau, etc..)? Que faire si le pare-feu du bureau ne laisse pas passer les connexions entrantes?

Cependant, j'aime bien le principe de Retroshare. L'utilisation du chiffrement des données entre l'expéditeur et le destinataire par clés asymétriques (GPG) permet de ne plus avoir besoin ni de contrôler l'accès aux données ni de sécuriser leur transmission.

Mon idée est d'améliorer le principe de Retroshare en ajoutant un "cache" chiffré de nos données personnelles sur un espace de stockage accessible 24/24 par le net (p2p, serveur ftp d'un copain, espace perso Free, autohébergement, etc...).

Exemple, avec Paul et Sarah.

Paul a un logiciel de réseau social sur son Macbook. Il ajoute ses photos de vacances à la mer avec Sarah dans le portfolio "Amis". Cette action envoie ses photos sur un espace de stockage sur le net. Paul se déconnecte.

Sarah allume son téléphone ou elle a un logiciel de réseau social. Elle fait partie des amis de Paul. De ce fait, son logiciel sait où Paul stocke ses données de réseau social sur le net. (il peut y avoir une redondance des données sur plusieurs espaces d'ailleurs). Le logiciel va regarder si il y a des nouveautés dans l'espace de Paul et trouve un nouveau fichier. Ce fichier est chiffré et seuls les détenteurs de la clé de déchiffrement "amis de Paul" peuvent la lire. Ca tombe bien, Sarah possède cette clé. Sarah télécharge donc le nouveau fichier et peut accéder aux photos de ses vacances à la mer avec Paul.

Rien n'empêche Sarah de partager la clé de déchifrement "amis de Paul" avec d'autres amis, Paul risque de ne pas être content si les amis de Sarah arrivent à voir ses photos. Néanmoins à partir du moment où Sarah peut voir les photos de Paul depuis son propre terminal, rien ne l'empêche de les rediffuser... Est-ce donc un risque intrinsèque au mode de fonctionnement des réseaux sociaux actuels?

La clé de déchiffrement "amis de Paul" a été transmise à Sarah par un moyen sécurisé. Chaque personne possède un couple de clé asymétrique type GPG. Des couples de clés aymétriques supplémentaires similaires sont créés pour les groupes/cercles de partage.

Un fichier "Index" est disponible sur l'espace de stockage des profils, celui ci indique où son rangés les fichiers du profil, quelle clé est nécessaire pour les déchiffrer. Ce fichier, permet de suivre l'arrivée de nouveaux éléments sur le profil de ses amis à la manière d'un flux RSS.

Un autre fichier "Présence" indique où se trouve les copies redondantes des données du profil. Ca peut être utile de savoir cela, si par exemple, l'espace de stockage est temporaire. Ce fichier indique aussi si l'utilisateur est en ligne, avec "l'adresse IP" pour le joindre. De cette manière si deux utilisateurs sont en ligne, des fonctions temps-réel peuvent être utilisées comme de la messagerie instantanée, voip, etc....

Les fichiers Index, Présence, etc... sont chiffrés avec la clé privée de Paul. Cela garantit à Sarah qu'ils n'ont pas été altérés par une tierce personne.

La sécurité des données est basée sur le chiffrement, or celui ci est seulement une protection de durée. Je veux dire par là qu'il est peut-être raisonnable de dire que dans 50 ans on pourra casser facilement les méthodes de chiffrement actuels (ordinateurs quantiques, failles dans l'algorithme...). Dès lors il peut être utile de rajouter une petite protection d'accès aux données chiffrées (password, clé d'accès au répertoire, adresse de stockage secrète) en plus du chiffrement des données afin d'éviter que trop de malins s'amusent à archiver les données chiffrées contenant la vie privée des personnalités en espérant les déchiffrer plus tard.

• l'interface Touchwizz très réussie.
• le partage de connexion par wifi (tethering) quand android ne le proposait pas en standard.

Mais aussi des mauvaises :

• Système de fichiers propriétaire responsable d'une réactivité douteuse de l'interface.
• Petits lot d'applications Samsung (Layar, Wiget socialiste, Market Samsung...) impossibles à désinstaller.
• Pas d'accès root.
• Sortie de nouvelles versions de l'OS selon le bon vouloir de Samsung (toujours pas d'android 2.3 en vue...)

Mon regard s'est donc tourné vers Cyanogen, un distribution Android/linux communautaire. Ce n'est que depuis peu que l'on peut l'installer sur Galaxy S car il ne faut pas oublier que même si Android est libre, les drivers ne sont pas toujours disponibles pour tous les appareils du marché (je ne sais pas si ceux-ci sont libres d'ailleurs).

J'ai donc suivi le didacticiel pour installer Cyanogen.

Astuces

Voici mes petites astuces complémentaires:

Pour le backup de mes données non stockées sur la carte mémoire (contacts, agenda, sms, journal d'appel), je n'ai pas trouvé de logiciel adéquat, j'attends vos suggestions sur ce point. J'ai réussi avec un programme du market qui m'avait l'air d'un bon spyware. C'est honteux qu'il n'y ait pas de fonction d'import/export dans la versions Samsung d'android.

Heimdall permet de changer le kernel de votre téléphone depuis linux afin d'être root.

Le paquet comprenant l'interface graphique ayant des problèmes de dépendances avec ma Debian stable. Néanmoins la commande suivante fait le même boulot que ce qui est décrit dans le didacticiel :

$ heimdall flash --kernel zImage-i9000

Bilan

Mon ressentiment sur Cyanogen à l'utilisation est que l'interface est plus rapide et surtout sans lag. Le clavier FR est tip-top. La déco de l'interface est assez customisable (nombreux thèmes, recherchez "ADW theme" sur le market, j'ai même retrouvé les icônes Samsung). C'est Android 2.3.4/kernel 2.6.35, assez à jour donc.

L'interface est par contre moins jolie et pratique que celle de Samsung (sms, journal d'appel, liste de contact, appareil photo, réveil). Les préférences sont assez fouillies. Au niveau autonomie, je n'ai pas constaté de différence : environ 40h selon mon utilisation.

Une fois root, vous pouvez supprimer la pub dans toutes les applications grâce à Adfree qui les bloque dans le fichier /etc/hosts. Pas besoin de passer à Cyanogen pour cela mais ça change la vie.

Mise à jour

Vous pouvez suivre les évolutions de Cyanogen pour votre téléphone en regardant le changelog. Il comporte des liens pour télécharger la dernière version de développement (nightly). Pour mettre à jour Cyanogen, il suffit de télécharger la nightly build sur l'espace de stockage de votre téléphone, puis en cliquant dessus depuis l'explorateur de fichier du téléphone, Clockworkmod va installer tout seul la mise à jour. (Conserver les options par défaut au popup qui s'ouvrira). Il n'y a normalement pas de perte de données.