Return-Path: <educ-owner@april.org>
X-Original-To: jtadeusz@april.org
Delivered-To: jtadeusz@april.org
Received: from localhost (unknown [192.168.2.16])
	by pavot.april.org (Postfix) with ESMTP id DF9FB11C031D;
	Wed, 11 Dec 2013 17:48:33 +0100 (CET)
Received: from pavot.april.org ([192.168.2.17])
	by localhost (spamvir.april.org [192.168.2.16]) (amavisd-new, port 10024)
	with ESMTP id MpcfNluuWtVg; Wed, 11 Dec 2013 17:48:33 +0100 (CET)
Received: by pavot.april.org (Postfix, from userid 102)
	id 56D2211C031E; Wed, 11 Dec 2013 17:48:32 +0100 (CET)
Received: from localhost (unknown [192.168.2.16])
	by pavot.april.org (Postfix) with ESMTP id 9C6BA1530E16
	for <educ@april.org>; Wed, 11 Dec 2013 17:48:27 +0100 (CET)
Received: from pavot.april.org ([192.168.2.17])
	by localhost (spamvir.april.org [192.168.2.16]) (amavisd-new, port 10024)
	with ESMTP id LHvRSJ1eQfTp for <educ@april.org>;
	Wed, 11 Dec 2013 17:48:23 +0100 (CET)
Received: from smtp1.tech.numericable.fr (smtp1.tech.numericable.fr [82.216.111.37])
	by pavot.april.org (Postfix) with ESMTP id 0DD5F1530E1A
	for <educ@april.org>; Wed, 11 Dec 2013 17:48:22 +0100 (CET)
Received: from [192.168.0.10] (81-66-46-103.rev.numericable.fr [81.66.46.103])
	by smtp1.tech.numericable.fr (Postfix) with ESMTP id 1C33C13F654
	for <educ@april.org>; Wed, 11 Dec 2013 17:48:22 +0100 (CET)
Message-ID: <52A89755.3080009@ac-reims.fr>
Date: Wed, 11 Dec 2013 17:48:21 +0100
From: fabio <fabio.pasqualini@ac-reims.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20121216 Icedove/3.0.11
MIME-Version: 1.0
To: educ@april.org
References: <1520547220.639905397.1386755214498.JavaMail.root@zimbra18-e3.priv.proxad.net> <52A85EB6.7090008@carlit.net>
In-Reply-To: <52A85EB6.7090008@carlit.net>
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiledrledugddugecutefuodetggdotefrucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfenuceurghilhhouhhtmecufedttdenuc
Subject: =?UTF-8?B?UmU6IFJlwqA6IFJlOiBbRURVQ10=?= =?UTF-8?Q?Rappel_=3A_Win?=
 =?UTF-8?Q?dows_XP_compte_=C3=A0_rebours?=
X-Loop: educ@april.org
X-Sequence: 5433
Errors-to: educ-owner@april.org
Precedence: list
Precedence: bulk
Sender: educ-request@april.org
X-no-archive: yes
List-Id: <educ.april.org>
List-Help: <mailto:sympa@april.org?subject=help>
List-Subscribe: <mailto:sympa@april.org?subject=subscribe%20educ>
List-Unsubscribe: <mailto:sympa@april.org?subject=unsubscribe%20educ>
List-Post: <mailto:educ@april.org>
List-Owner: <mailto:educ-request@april.org>
List-Archive: <https://listes.april.org/wws/arc/educ>
Content-type: multipart/mixed;
  boundary="----------=_1386780508-12485-439"
X-Length: 19889
Status: R
X-Status: NT
X-KMail-EncryptionState:  
X-KMail-SignatureState:  
X-KMail-MDN-Sent:  
X-UID: 0

This is a multi-part message in MIME format...

------------=_1386780508-12485-439
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Bonjour,

Merci pour ce propos riche.

Dans un monde idéal, il y a la maîtrise d'ouvrage (MOA), celle qui 
définit les attentes, les besoins et les exigences liés au métier, ici 
l'éducation nationale ou ses acteurs.

Puis il y a celui qui met en musique tout cela, la maîtrise d'oeuvre 
(MOE), et là il est préférable d'avoir un professionnel (comme dit 
Charlie, chacun son métier).

Le problème est que chacun a du mal à trouver sa place ! La MOA parce 
qu'elle a tendance à prescrire des solutions techniques au lieu de bien 
définir ses besoins métier !
Et la maîtrise d'oeuvre qui a tendance à proposer des solutions non 
conformes aux exigences du MOA pour plein de raisons : manque de temps, 
manque de compétences, marge immédiate, modèle économique ...

Enfin, il y a les endroits où cette approche est très délicate parce que 
la personne qui s'occupe de l'informatique est MOA, MOE et petites mains 
! De quoi devenir schizophrène !

Je crois qu'il faut se centrer sur la posture du MOA et définir les 
exigences métier, elles aboutiront vers une solution libre (enfin, nous 
en sommes convaincus ici ;) ).

Prenons un exemple simple, posons comme condition que la solution ne 
soit pas intrusive et qu'il doit y avoir confidentialité des résultats 
des élèves. Les systèmes propriétaires se disqualifient de suite. 
Certes, ils garantiront la confidentialité sur papier mais ne pourront 
la prouver (un analyseur de trames montrera qu'il existe des échanges 
avec l'extérieur sur des sites qui n'appartiennent pas à l'organisation 
demandeuse et de plus, ils sont rarement Open Source). Il est souvent 
impossible pour eux de prouver que la confidentialité est assurée, de 
plus, grâce à Edward Snowden, nous avons à dire sur ce sujet !

On peut aussi travailler sur les conditions générales d'utilisation :
voir le site
http://tosdr.org/
Il est facile de trouver des conditions que l'on jugera comme abusives 
et qui disqualifieront une solution propriétaire.

Je le redis, un des premiers défauts quand on pense numérique est de 
définir la solution avant les besoins ! Combien de fois a-t-on vu comme 
projet : "acheter des tablettes" ! "Acheter des tablettes" n'est 
sûrement pas un besoin métier mais bien une solution technique à un 
besoin métier qu'il faut définir. Travaillons ce point et proposons des 
besoins métier qui mettent en évidence l'intérêt du choix d'une solution 
libre.

Bon courage et librement,
Fabio


Le 11/12/2013 13:46, Pierre Yann Baco a écrit :
> Bonjour.
>
> Le 11/12/2013 10:46, cnestel@free.fr a écrit :
>> ----- bdesroches@free.fr a écrit :
>>> Non tu n'es pas en dehors de la discussion, tu es même en plein dedans !
>>> mais ne crois pas trop au mirage des techniciens du second degré, ce
>>> sont trop
>>> souvent des formatés M$ et le résultat est pire que tout...
>>
>> Pardon, mais à mon humble avis tu amalgames deux problèmes que l'on
>> devrait traiter de manière disjointe.
>>
>> a) Comme l'a très bien démontré Thierry Munoz, il n'y a pas d'autre
>> voie que la gestion de l'informatique des écoles primaires par
>> des techniciens dépendant de telle ou telle administration (par
>> exemple les mairies) à définir.
>>
> J'ai dû rater le post de Thierry Munoz, mais je ne vois pas en quoi il
> n'y aurait d'autre voie que la gestion des écoles primaires par des
> "techniciens dépendant de telle ou telle administration".
>
> Ca fait 9 ans que j'installe et maintiens l'informatique dans plus de 35
> écoles primaires de mon département (pour un total d'environ 450 à 500
> clients légers Linux/LTSP, plus tout l'héritage Windows présent, au
> total pas loin de 650 postes), dans autant de petites communes
> différentes. Je crois connaître un peu le sujet des relations entre
> académie, écoles, mairies, communautés de communes ou d'agglos, conseil
> régional et autres syndicats intercommunaux en ce qui concerne
> "l'informatique scolaire en primaire".
>
> La réalité du terrain est que les choix d'équipement-fonctionnement
> (hard ou soft) sont:
> - toujours considérés comme d'importance mineure quand on les compare
> aux autres investissements nécessaires (et "visibles") dans une école.
> - par nature très hétéroclites et fragmentés. Une école primaire
> "communale" est un petit établissement, contrairement à un collège ou un
> lycée.
> - très variables pour la même raison: les écoles primaires voient
> souvent leur effectif varier très fortement d'une année à l'autre (avec
> ouverture/fermeture de classe fréquente). Leurs besoins évoluent donc en
> parallèle (à la hausse comme à la baisse).
> - exprimés d'abord par le personnel enseignant d'une école, avec de TRES
> fortes différences de connaissance du sujet, allant (rarement, ou dans
> le cas de la construction d'une nouvelle école) de la définition d'un
> projet précis et détaillé (câblage, salle info, choix d'OS et d'applis,
> modalités de maintenance), à "j'ai besoin d'un portable et de quelqu'un
> pour faire (re)marcher ces xx bécanes de 15 ans d'âge, le tout pour 300€
> et surtout pas Windows 8 ni Linux dont je n'ai jamais entendu parler".
> - éventuellement (mais pas souvent) "révisés" ou commentés par un TIC de
> l'académie, quand celui-ci a le temps, ou quand il y en a un, car dans
> quelques académies, les TIC ont tellement d'écoles à gérer-maintenir
> qu'ils sont vraiment débordés.
> - négociés entre la direction de l'école et la commune, ou la communauté
> de communes, ou le syndicat mixte, et dans chaque cas (bien différent
> car les enjeux politiques et économiques locaux sont à prendre en
> compte) ce n'est pas simple. Cela se termine souvent par un "petit"
> appel d'offre (ou une simple demande de devis auprès de 3 sociétés du
> coin, quand les montants estimés sont peu élevés).
> - pondérés par le poids de "l'existant", c'est à dire le parc de
> vieilles brelles héritées des généreux donateurs (parents, mairie etc),
> qui malgré leur bonne volonté, n'arrivent pas à comprendre que la salle
> informatique d'une école n'est pas une poubelle destinée à recueillir
> toute l'obsolescence du monde...
> - toujours "filtrés", et à chaque étape, par la compétence informatique
> de chaque intervenant dans le processus, par la vision simplement
> quantitative ("15 postes pourris c'est mieux que 8 qui fonctionnent
> bien"), par le poids des habitudes ("ça sera Outlook + Word + Jocatop et
> Adibou ou rien, parce que j'ai 10 ans d'email à récupérer et les 20 CDs
> que la coop de l'école a acheté y'a 3 ans").
> - rabotés par ceux qui répondent à l'appel d'offre (ou la demande de
> devis simple), qui proposent des "solutions catalogue" ou à la mode
> (classes portable, TBI, etc) sans aucun suivi, alors que le milieu
> scolaire est très "corrosif" pour du hard ou du soft mal installé ou
> sécurisé. J'ai moi même récupéré la maintenance de plusieurs de ces
> solutions miracle (dont pas mal de "classes portables") abandonnées par
> les fournisseurs aux bons soins d'une équipe enseignante confrontée à un
> "User Guide" en serbo-croate, quand il y en a un...
> - ou au contraire gonflés au maximum par les mêmes, quand ils savent que
> la commune ne dispose pas des connaissances suffisantes pour décortiquer
> un devis (et il faut voir les devis faisant la course au Ghz et au
> To!!). Sans compter les ententes préalables entre fournisseurs (y
> compris ceux qui m'appellent pour demander de "me coucher" dans telle ou
> telle commune...)
> - influencées par les avis plus ou moins éclairées des parents (ou du
> beau-frère qui s'y connaît). Cela peut aller jusqu'à demander la
> déconnexion du Wi-Fi par principe de précaution, dans une école où il
> n'y a pas de filaire, et qu'il n'est pas possible (ou bien trop cher)
> d'en installer, ou à l'achat d'Ipad, parce que "j'ai le même à la maison".
> - et finalement résolue par la livraison (par le "moins disant") d'une
> palette de matos qui n'est toujours pas opérationnelle après 6 mois, car
> le personnel enseignant n'a pas le temps de s'en occuper.
> L'installation, le paramétrage, la formation et la maintenance sont trop
> souvent délaissés. Quand l'école dispose d'un enseignant compétent et/ou
> volontaire en la matière, il doit trop souvent tout prendre en charge,
> et en dehors de ses heures de cours...
>
> A lire cette liste, on pourrait donc croire que Thierry Munoz a raison
> de dire que "la gestion de l'informatique des écoles primaires par
> des techniciens dépendant de telle ou telle administration (par
> exemple les mairies)" est la seule solution.
>
> Mais, du moins en ce qui concerne mon département "rural":
> - AUCUNE des mairies dont je m'occupe ne dispose d'un technicien
> informatique. Et une embauche est tout simplement économiquement
> impossible. Dans mon département, il doit y avoir moins de 20 communes
> sur 226 qui disposent d'un technicien informatique.
> - Certaines se regroupent (syndicats mixtes ou communautés de communes).
> Mais la compétence de ces regroupements concerne les investissements
> (bâtiments, voirie, eau, collectes des ordures, transport, culture,
> sport), TRES rarement les services scolaires pour lesquels chaque
> commune souhaite garder son indépendance. Les enjeux politiques locaux
> sont très/trop sensibles et trop complexes pour être mis à plat et
> systématisés.
>
> L'académie, par le biais de ses TIC/MATIC (ou autre appellation) a son
> rôle à jouer quant à la gestion de l'informatique d'une école. Elle le
> fait, mais avec les moyens dont elle dispose. Dans mon académie, le
> nombre de TIC diminue chaque année (avec des TIC parfois à 1/2 temps).
> J'en connais beaucoup, et ils font du bon travail. Mais ils ont aussi
> (et surtout) à gérer l'aspect "informatique administrative" des écoles,
> où chaque directeur a un poste dédié à cet usage (Base Elève, messagerie
> académique, etc). Il faut bien distinguer ces deux aspects (informatique
> éducative et informatique administrative).
>
> Certaines académies proposent des contrats de maintenance aux communes.
> Même problème: les équipes sont débordées. Elles doivent se battre avec
> du matos qu'elles n'ont pas "calibré" et souvent "hérité" (y'avait
> encore du Windows Me ou 95 l'année dernière). Comment monter un système
> opérationnel et ouvert dans ces conditions ?
>
> Pour terminer, je pense que la solution en ce qui concerne la gestion
> informatique des écoles primaires se situe "entre les deux":
> - l'éducation nationale doit rester maître en ce qui concerne les
> enjeux, les projets et les usages des systèmes informatiques primaires
> (éducatif et administratif).
> - Ceci peut (doit) être défini par un cahier des charges "ouvert",
> précisant les objectifs et les besoins à couvrir, que ce soit dans
> l'investissement (le matériel, le logiciel, la formation) et le
> fonctionnement (la maintenance).
> - C'est à ce niveau que « l'incitation au développement de ressources
> numériques se fera [..] en faveur de logiciels libres et de contenus aux
> formats ouverts ».
> - La demande d'une école primaire doit donc respecter ce cahier des
> charges (notamment en éliminant les demandes spécifiques à un
> fournisseur/éditeur comme on en voit trop souvent).
> - L'académie a ici un premier rôle à jouer en validant la demande d'une
> école avant qu'elle soit soumise à une commune pour financement.
> - N'importe quelle société/prestataire doit pouvoir répondre à une
> demande d'une école en respectant ce cahier des charges.
> - Une fois reçues par les communes (qui financent), les réponses
> pourraient être regroupées pour envoi "consultatif" vers l'éducation
> nationale, au niveau local (inspection académique, au niveau
> départemental), où la connaissance des prestataires et des besoins des
> écoles et de leurs besoins est plus facile à vérifier et à mettre à jour.
> - L'académie aura ici la possibilité de "valider" une ou plusieurs
> réponses, sans forcément en choisir une précise, car le choix doit
> rester à la commune. Elle peut aussi indiquer que telle ou telle autre
> réponse n'est pas appropriée et qu'en conséquence elle ne ferait l'objet
> d'aucun soutien de sa part (formation interne des enseignants,
> éventuelle maintenance logicielle, accès aux ressources académiques,
> etc) si elle était retenue par la commune, ce qui peut aussi avoir un
> impact significatif.
>
> En résumé, l'académie aurait ainsi la possibilité:
> - de vérifier que les demandes des enseignants en ce qui concerne leur
> informatique "locale" correspondent aux enjeux et objectifs définis et à
> l'ouverture souhaitée, notamment en ce qui concerne le libre.
> - de vérifier que les prestataires locaux répondent en conséquence.
> - de renseigner les communes (et surtout les petites!) quant à la
> qualité des réponses, tout en leur laissant le choix du prestataire.
> - "d'influencer" les communes quant à ce choix, en refusant de
> s'investir dans l'utilisation d'un système qui ne répond pas aux critères.
> - de vérifier périodiquement, sur site, et sur le long terme la
> pérennité de la solution retenue et son suivi (maintenance, formation)
> par le prestataire qui en a la charge.
>
> De son côté, la commune aurait la possibilité:
> - de récupérer les demandes des écoles mieux structurées et
> "pré-validées" par l'académie.
> - d'obtenir une aide quant à la lecture des réponses des
> prestataires/fournisseurs locaux. Et ça, c'est essentiel!!!
> - de rester libre quant au choix du prestataire.
>
> Enfin, ceci permettrait de construire, auprès des plus intéressés
> (TICE/MATIC, personnel enseignant, communes) une base/liste de
> prestataires LOCAUX "qualifiés" et compétents dans le domaine du libre.
>
> Cela demanderait effectivement des ressources au niveau des académies,
> notamment auprès des TICE/MATIC (chargés de valider les
> demandes/réponses), mais ils recevraient en contrepartie le soutien des
> prestataires en ce qui concerne la formation, le suivi et la maintenance
> sur site, ce qui réduirait d'autant leur charge de travail.
>
> Pour terminer, juste un mot sur les "techniciens formatés Microsoft": En
> ce qui concerne les TICE/MATIC (ceux que je connais), il y en a, c'est
> vrai, mais "par défaut". Mais ils sont demandeurs et ouverts à tout. Il
> y a toujours moyen de les former et/ou de leur faire découvrir le libre
> (dont Linux). Reste que l'APRIL, d'autres assos (et mêmes des
> prestaires) auraient donc tout intérêt à leur proposer directement des
> "formations/introductions/install parties/etc" pour limiter ce problème
> de "formatage Msoft". J'ai pu le faire ici, à mon niveau. Peut-être
> suis-je dans une académie particulièrement "ouverte" ?
>
> Voilà, c'était juste en passant (et un peu long, désolé), un mercredi
> matin, jour où les écoles sont pour l'instant fermées, et qu'il me
> restait un peu de temps pour contribuer du fond de ma province.
>
> A+
> Pierre
>
>> b) Le fait que les techniciens soient formatés Microsoft est
>> un autre problème que nous devons prendre en compte :
>>
>> - pacte du logiciel libre
>> - références à la directive Ayrault
>> - références à la loi sur la refondation de l'école qui recommande :
>> « l'incitation au développement de ressources numériques se fera
>> notamment
>> en faveur de logiciels libres et de contenus aux formats ouverts »
>> - référence à la souveraineté informatique
>> - référence aux enjeux fiscaux
>> - nécessité de former les techniciens
>> - autres
>>
>> Nous devons nous positionner dans une stratégie. L'April ne peut
>> pas agir localement.
>>
>> Il nous faut préparer la lettre de demande d'audience auprès
>> de Catherine Becchetti-Bizot et d'Alain Boissinot, sans oublier
>> la préparation des amendements pour l'acte 2 de l'exception
>> culturelle où il sera question de l'exception pédagogique
>> avec un certain nombre de pistes et de propositions.
>>
>> Sans oublier les points de convergences avec les autres assoces.
>> On a aussi en chantier les propositions à Pagestec.
>>
>> Librement,
>> Charlie
>>
>>
>

------------=_1386780508-12485-439
Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: 8bit

--
Pour gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ

------------=_1386780508-12485-439--
