Réactions  aux spécifications fonctionnelles d'un intranet  administratif
http://www.admiroutes.asso.fr/espace/intranet/methode/specif.htm

pages

par Laurent.Rieuneau@justice.gouv.fr avec les réponses d'Anne Bedel en rouge italique

06-04-2002

Voir aussi la réaction de Didier Georgieff
 
Date: Sat, 6 Apr 2002 12:08:48 +0200
From: RIEUNEAU Laurent <Laurent.Rieuneau@justice.gouv.fr>
Organization: CJN/BAI

Bonjour anne,

quelques remarques au sujet de la page
Spécifications fonctionnelles d'un intranet administratif: http://www.admiroutes.asso.fr/espace/intranet/methode/specif.htm :

Acteurs et gestion des droits
- il est peut-être dommage de lier arborescence du site (vision externe) et répertoires (vision physique) dans les spécifications : d'abord dans bien des cas, il n'y a pas de répertoire (cas de documents stockés dans des bases de données ou d'infos mises en forme à la demande), ensuite parce que c'est une vision très réductrice de la richesse qu'offrent les serveurs HTTP (apache, par exemple ;-) en terme d'alias, de répertoire virtuel, sans compter les "softlinks" unix qui permettent de faire apparaitre un même document (ou répertoire) à plusieurs endroits et sous des noms différents.
Pour moi les répertoires font partie de l'arborescence. Par ailleurs il y a des "vues" possibles d'un document à partir d'autres répertoires, bien qu'il soit "rangé" physiquement qu'une seule fois dans un seul répertoire.
Si je comprend bien, on peut avoir un même document avec des noms différents?
Par ailleurs, si l'on souhaite que chaque document ait une URL stable, il faut bien une arborescence avec des répertoires?AB

- la demande de validation par mel au valideur n'est une bonne idée que pour des sites très réduits : au delà de quelques dizaines de pages par jour, un unique message informant qu'il y a des pages à valider, et un outil en ligne de validation (avec liste, etc) serait préférable pour ne pas crouler sous les mails engorgeant la bal des valideurs.
Tout à fait d'accord et d'ailleurs j'ai bien précisé: "s'il le souhaite, il pourra occulter cette fonctionnalité"

- sauf justification fonctionnelle à expliciter (annuaire préexistant, autres usages ?), je ne vois pas ce que fait LDAP dans des spécifications : c'est un choix technique (qui d'ailleurs ne se suffit pas à lui-même pour la gestion des droits, par exemple), et qui trouverait plus sa place dans un document d'architecture technique (type de serveur HTTP, système d'exploitation, etc); à mélanger du technique et du fonctionnel, on prend le risque d'être incohérent, ou de brider artificiellement et précocement les choix de développement.
Dans l'intranet casier par exemple, que nous avons entièrement reconstruit et élargi (300 utilisateurs), nous gérons des droits et des pages dynamiques avec une table MySQL, ce qui nous dispense d'avoir en plus un serveur LDAP.
D'ailleurs, contrairement à ce qui est écrit dans les principes de fonctionnement du portail, l'utilisateur n'est pas reconnu "par" l'annuaire LDAP, mais dans le meilleur des cas, "grâce à" l'annuaire LDAP (le reste relève de l'authentification HTTP, ou applicative, via cookie, etc ...)
Vous avez raison, j'ai retiré la référence à LDAP.

maquette "mon intranet" :
une remarque à propos de "Vous avez 10 nouveaux messages dont 2 urgents" :
ca n'est ni simple, ni rapide d'obtenir un tel affichage. Dans la plupart des cas (messagerie pop3 ou IMAP), il faut balayer la boite aux lettres pour compter les mails, et identifier les priorités de chaque mail. Pour l'avoir testé sur une messagerie IMAP et alors que le tout était sur le même serveur et les accès en réseau local (donc temps de réponse bons), je peux dire qu'on y renonce vite (trop lent) : nous nous contentons d'afficher "vous avez du courrier" ou "vous n'avez pas de courrier" (en ne testant que les dates d'accès et de modification des boites aux lettres, pas leur contenu).
C'est une information très utile pour en discuter avec le prestataire

outil statistique :

- qu'il soit une véritable outil d'évaluation, certes; mais pourquoi devrait-il être utilisé par tous ?
Quiconque met un document en ligne a légitimement envie de savoir si il est lu ou non.

De plus, l'idée de comptabiliser le nombre d'impression est irréalisable (sauf à prévoir un bouton "impression" sur chaque page, avec comptage associé, et encore, ca n'empêchera personne de faire 'fichier imprimer' ...). Enfin la notion de temps passé sur les pages n'a pas de réalité, car le HTTP l'ignore : on peut tout au plus calculer le temps écoulé entre 2 requètes d'un même utilisateur (qui a pu faire autre chose entre temps ;-)

Vous écrivez "les outils standards analysent les fichiers logs. D'autres fonctionnent avec des marqueurs de type www.xiti.com <http://www.xiti.com> (merci de m'indiquer la différence)":

Les logs sont des fichiers du serveur qui enregistrent ce qu'on lui a demandé et ses réponses (et bien d'autres choses paramétrables); les outils courants (car il n'y a pas d'outils standards), tel analog, permettent d'en tirer une multitude d'infos; les marqueurs cités sont des compteurs plus ou moins sophistiqués traités par un autre serveur (ce qui suppose d'ailleurs un accès au Web) qui doivent être insérés volontairement dans les pages que l'on souhaite inclure dans les stats :

c'est donc moins riche et beaucoup plus contraignant à utiliser (outre l'apparition, en général, du logo de la société qui propose un tel service, pas forcément en harmonie avec la charte graphique du site).

intégration :
Le concept relève plus d'un cahier des charges techniques que de spécifications. D'ailleurs les explications qui suivent ne relèvent pas de la notion d'intégration, mais d'aspects fonctionnels (sauf peut-être l'utilisation de LDAP, mais il faudrait alors préciser quelque chose comme "l'authentification HTTP s'appuyera sur un annuaire LDAP"). Dans un document technique, on pourrait en revanche évoquer l'intégration de Apache, MySQL, LDAP, etc, sur une plate-forme de type xyz...

"L'intégration devra être assurée par un prestataire n'ayant pas partie prenante dans un des outils" : ca mériterait d'être nuancé (notion d'outil floue, comme celle de logiciel) : au pied de la lettre, ca interdirait à un prestataire qui développerait des modules web dynamiques adhoc pour répondre aux  spécifications de les mettre en place pour construire l'intranet souhaité.
Entièrement d'accord, je retire ceci du document

Charte graphique :
Plutot que monoframe, je dirais sans cadre ("frames HTML"), si c'est bien ce qui est souhaité. La encore, c'est peut-être une restriction technique un peu précoce (les frames cachées apportent des solutions techniques parfois intéressantes, notamment pour garder des données temporaires entre pages).

page type : http://www.admiroutes.asso.fr/espace/intranet/methode/pagetype.htm
- le bouton "déconnexion" n'a pas de sens HTTP (c'est un mode non-connecté)
Imaginons que je me connecte sur mon intranet d'un cybercafé, d'un hôtel ou d'un autre ministère. Je souhaite me déconnecter quand j'ai fini afin que personne ne puisse poursuivre la navigation derrière moi (qui je le rappelle, m'est personnalisée)

- l'historique de navigation soit fait doublon avec celui du navigateur, soit ne représente au mieux que la place d'un document dans une arborescence hiérarchique plus ou moins fixe.
Je précise que dans le cas qui nous occupe, l'historique de navigation permet de représenter la place du document dans l'arborescence.

"afin d'éviter lors de l'impression couleur de la page de vider les cartouches d'encre." : c'est de l'humour ? Sinon, je dirais que:

  1. il y a une antinomie irréductible entre affichage écran et impression papier,
    Peut-être, n'empêche qu'actuellement, le bandeau de notre intranet s'imprime en turquoise (ou en gris), et que je trouve cela inutile.
    Disons qu'il faut éviter les couleurs de fond ou de bandeau ou alors prendre des pastels très clairs.

  2. on ne peut pas controler les options d'impression de l'utilisateur et

  3. dans l'administration, on voit plus d'imprimante N&B que jet d'encre couleur ;-)
    Mais il y en a de plus en plus et cela ira en s'accélérant.

Cela étant dit, votre page est pleine de bonnes suggestions; elle pourrait contenir plus d'exemples réels (et pour beaucoup, gratuits) de ce que vous évoquez : cf spip et PHPnuke par exemple, pour l'aspect mise en ligne, compteurs, validations, qui répondent à la quasi-totalité de vos points.

http://www.admiroutes.asso.fr/espace/intranet/methode/reaclr.htm
droits diffusion