Discussion:Serveur informatique

Matériel vs logiciel

Bonjour, Je pense qu'il serait intéressant de bien distinguer les serveurs matériels des serveurs logiciels et expliquer qu'un serveur logiciel peut utiliser une architecture de plusieurs matériels et qu'à l'inverse, un même matériel peut être serveur de différents "services". Il est aussi possible de prendre l'exemple d'un webmail où le premier client est l'utilisateur et son ordinateur (on ne parle pas de serveur graphique de ce client) qu'il accède à un serveur web qui lui-même va se trouver client du serveur pop.

Chmanu

Avec l'avènement des nouvelles technologies de communication, on peut comparer la notion de client/serveur à la communication humaine : à savoir que les gens échangent des informations en suivant un protocole bien défini (requête/réponse)qui garantit la qualité de nos rapports. De la même façon, les machinent dialoguent entre elles et échangent des informations : cela va de la résolution d'une adresse IP (difficile à retenir pour un homme) en un nom (par ex wikipedia.org), en passant par le routage (les passerelles par lesquelles transitent les informations en vue d'optimiser les échangent).Dans la réalité, il faut bien voir que le serveur fournit une réponse à une demande et le client demande. Bien sur, cette vision peut se décliner à l'infini étant donné que la toile est grande et le serveur se transforme aussi tres vite en client lorsqu'il en a besoin.

Métaphore du paradigme client/serveur

Le paradigme client/serveur introduit la notion de services que l'on peut comparer avec la métaphore du serveur de restaurant.

Le client entre dans le restaurant (début de la session) pour se restaurer (service fournit par le restaurant). Le client commande (requête non bloquante) au serveur un plat cuisiné (consommation d'un service). Ce service est engagé par une requête (la commande du client) et un ou plusieurs processus sont executés (la préparation du plat). Au terme de ces processus, le serveur sert le plat au client (réponse à la requête "commande"). Le client consomme le plat cuisiné (consommation des ressources). Le service prend fin au paiement de la facture (fin de session).

Les clients consomment des services qui s'effectuent en parallèle (dans le meilleure des cas) dans le restaurant. Le client peut consommer d'autres services en attendant qu'on lui serve son plat principal (premier service).

La notion de service satifait pusieurs requêtes différentes et plusieurs réponses différentes.

--Ghostrider(pth)

Dans les services offerts par un serveur le terme transfert pour "transfert le courrier électronique" ne me parait pas tout à fait correcte. Je mettrais plutôt "gérer le courrier électronique" car vis à vis de la messagerie un serveur intervient dans des tâches de stockage, de gestion des droits d'accès, etc.

--Drambeau 8 septembre 2006 à 09:45 (CEST)

serveur informatique

le concept CLIENT-SERVER

En réalité, on a bêtement traduit un américanisme du type "marketoïd" comme disent eux-mêmes les Yankees. L'illustration du serveur de restaurant est justement le piège où il ne fallait pas tomber, car le serveur que nous connaissons offre un service d'hôtellerie bien concret (en anglo-saxon: waiter). Ce que ne font pas les logiciels mis en œuvre. Un "serveur" ne vous apportera pas hélas! le café sur votre bureau. (ou alors il se nommera robot ou autre). Restons dans l'informatique. Le défaut récurrent de la 'mini-informatique' est, en remontant le temps, de se limiter à son apparition. Dans les années 70, les ordinateurs étaient souvent beaucoup plus puissants que ce qui est déclaré dans l'article. Passons. Les termes anglais classiques (donc étymologiquement purs) employés lors de la conception de ce système (années 1970) étaient "request(er)/ respond(er)" (réponse à une demande). Ce qui est une traduction orthodoxe. Bien entendu, la réponse était à la mesure de la disponibilité des ressources gérables par l'ordinateur central. Attaleiv (d) 17 mars 2008 à 23:04 (CET)

Oui et après... . GLec (d) 7 mars 2009 à 12:33 (CET)

Le terme requester / responder pourrait être ajouté à une section "histoire", il apporterait une explication complémentaire sur le rôle d'un serveur.--Silex6 (d) 7 mars 2009 à 19:16 (CET)

Définition d'un serveur

Bonjour. à mon avis le mot serveur fait référence à un rôle. Ce rôle est pris en charge par un logiciel donné sur une machine donnée. La définition doit mettre l'accent sur le rôle (QUOI) plutôt que la technologie (COMMENT ?, TCP/IP, protocole, etc...). une section technologie pourrait détailler les architectures, les protocoles, etc... --Silex6 (d) 7 mars 2009 à 18:10 (CET)

Le serveur informatique est à la base un logiciel ou programme comme Apache HTTP Server associé à une machine et une liaison filaire (par exemple Ethernet ou sans fil). On ne peut donc dissocier les deux. De plus, à la différence d'un article comme "Informatique" où l'on peut se permettre un peu de vulgarisation, il faut chercher ici à garder un certain niveau (ne pas hésiter à mentionner les protocoles ou faire référence à des normes) tout en l'améliorant. Il faut aussi éviter de développer le coté "trop informatique personnelle"ou inventer des mots et des relations qui n'existent pas. Le monde des serveurs informatiques est très lié à celui des normes et des protocoles et ne laisse pas beaucoup de place à la théorisation. GLec (d) 8 mars 2009 à 11:53 (CET)

D'accord avec toi que le matériel, le logiciel et la liaison réseau sont indissociables de la notion de serveur. on ne peut par contre pas en dire autant des (nombreuses) technologies associées, qui ne sont autres que des technologies liées à l'implémentation d'un serveur particulier (ce ne sont pas les technologies qui définissent ce qu'est un serveur). C'est pour cette raison que je préconise de détailler les technologies en dehors du résumé d'introduction, qui à mon avis doit rester vulgarisateur et ne requérir aucune connaissance particulière.--Silex6 (d) 8 mars 2009 à 13:17 (CET)

Qu'appelez-vous "implémentation d'un serveur particulier" et plus particulièrement "serveur particulier"? GLec (d) 8 mars 2009 à 13:27 (CET)

exemple: le protocole HTTP sert pour les serveurs web, le protocole NFS sert pour les serveurs de fichiers, etc...--Silex6 (d) 8 mars 2009 à 13:35 (CET)

En effet, il s'agit bien en fait de protocoles et non de "serveur particulier". Un serveur se définit par rapport à la pile de protocoles Internet dans le cas d'une application de type "Web" ou par rapport au modèle en couche OSI dans le cas plus général. Si on sort de ce cadre, on rentre dans le domaine de celui qui bricole son petit serveur dans son coin. Et là, il y a une littérature abondande et de multiples forums qui traitent du sujet. C'est pour cela qu'il faut éviter avec ce type d'article de tomber dans une certaine vulgarisation. GLec (d) 8 mars 2009 à 13:57 (CET)

GLec, je ne suis pas sur de comprendre vraiment ce que tu veut dire. Mais voici ma position par rapport au bricoleur dans son coin: il existe une abondance de guides pratiques à ce sujet, or Wikipédia n'est pas un guide pratique. Il donne un éclaircissement tout public, pas un mode d'emploi pour bricoleur (je t'apprends surement rien). Et le résumé introductif doit permettre à tout un chacun, même sans connaissance préalable de savoir de quoi l'article parle. Il est donc préférable de limiter le nombre de notions professionnelles et de jargon au strict minimum. Ceci est évidemment valable uniquement pour le résumé introductif, et l'article peut détailler en profondeur le sujet y compris toutes les notions professionnelles connexes...--Silex6 (d) 8 mars 2009 à 14:25 (CET)

Si votre objectif et de refaire ou de développer l'article, il serait préférable alors de faire vos propositions ici dans cette PdD. Par exemple une approche de type:

• Section: "Proposition N°1: Introduction".
• Sous-section: "Commentaires".
• Etc... .

donne de bons résultats avec ce type d'article. Amicalement, GLec (d) 8 mars 2009 à 17:45 (CET)

Proposition de plan

Bonjour. dans le but d'étendre et de réviser cet article, je propose le plan suivant:

• résumé d'introduction tout public. sans connaissance préalable. avec renvoi sur client (informatique) et réseau informatique.
• Introduction au concept de client/serveur. section centrée sur la technologie, courte explication avec envoi sur article détaillé client-serveur et introduction aux protocole de communication.
• Histoire: évolution depuis les mainframe. comme la section actuelle.
• Types de serveurs: serveurs de fichiers, serveur web, serveur d'imprimante, notion de web farm et clusters, section centrée sur les applications informatiques ...
• Matériel serveur: caractéristiques générale des serveurs (puissant matériel), fournisseurs importants.
• logiciels serveurs: caractéristiques générales des logiciels (notion de deamons), exemples d'applications courantes

Un plan semblable pourrait être appliqué à l'article client (informatique) (hormis la section sur le matériel).--Silex6 (d) 8 mars 2009 à 18:13 (CET)

Je ne crois pas que cet article est destiné à tous les publics ou est susceptible d'intéresser tous les publics. D'autres part le but de celui-ci n'est pas de donner des éléments pour constituer des fiches techniques ou commerciales par exemple. Il s'agit d'abord d'un article encyclopédique. L'article à seulement besoin d'être développé. Il est plus judicieux de revoir les sections Listes pour les remplacer par des paragraphes étoffés. Pour l'introduction vous pouvez déjà faire une proposition ci-dessous pour voir si celle-ci améliore vraiment celle en l'état. GLec (d) 8 mars 2009 à 18:40 (CET)

L'article est actuellement évalué d'importance élevée, c'est-à-dire qu'il couvre un large public, et pas uniquement des professionnels, non ?. Je ne pense pas qu'il soit une bonne idée de faire des fiches techniques, plutôt de parler des concepts et des technologies, et citer des fournisseurs notoires, mais uniquement à titre d´exemples. (les produits et les fournisseurs ca évolue, et puis WP n'est pas un guide d'achat).--Silex6 (d) 8 mars 2009 à 18:57 (CET)

résumé d'introduction

comme résumé d'introduction sans connaissance préalable requise, je propose le texte suivant:

---

Dans un réseau informatique, un serveur est l'élément dont le rôle est de traiter automatiquement les demandes envoyées par un client à travers le réseau. Est appellé serveur aussi bien l'ordinateur qui traite automatiquement les demandes que le logiciel qui contient les instructions relatives au traitements en question.

Les serveurs sont d'usage courant dans les entreprises, les institutions, et le réseau Internet, ou ils sont utilisés indirectement par de nombreux usagers pour stocker, partager et échanger des informations. Les différents usagers opèrent à partir d'un client - ordinateur personnel, poste de travail, ou terminal.

Le World wide web, la messagerie électronique et le partage de fichiers sont des applications pratiques qui font usage de serveurs.

---

à discuter, n'hésitez pas à apporter des améliorations ou des corrections.--Silex6 (d) 8 mars 2009 à 19:01 (CET)

Cette introduction n'améliore pas celle existante. En ce qui me concerne, elle est triviale est introduit une ligne directrice "commerciale" ou "publique" avec des termes comme "employés" ou "abonnés". Le mieux serait plutôt de se référer à l'article anglophone pour le développement de l'article. GLec (d) 8 mars 2009 à 19:37 (CET)

voici la définition de l'article anglophone: A server is a computer program that provides services to other computer programs (and their users), in the same or other computer. The physical computer that runs a server program is also often referred to as server. Services can be supplied centrally by the use of a server; in other cases all the machines on a network have the same status with no dedicated server, and services are supplied peer-to-peer. cette définition met en évidence le caractère central d'un serveur, et aborde le sujet du peer-to-peer. pour le reste la définition est triviale.

Je parlais de se référer à l'article en.WP pour le développement de sections et pas de l'introduction qui n'est pas meilleure que celle de cet article en l'état. Peut-être pouvez-voir de ce coté pour remplacer les deux sections qui ne sont que des listes de liens internes comme précisé plus haut. Le mieux c'est que vous fassiez un brouillon dans une de vos pages perso. Je verrai plus tard faute de temps. GLec (d) 8 mars 2009 à 20:22 (CET)

La ligne directrice institutions est voulue, les serveurs appartiennent le plus souvent aux institutions. De même que l'aspect trivial, le but: expliquer de manière triviale exactement ce qui est actuellement expliqué (qui est tout à fait correct).--Silex6 (d) 8 mars 2009 à 20:15 (CET)

J'ai remplacé le terme employé ou abonné par usager, plus général et moins commercial.--Silex6 (d) 9 mars 2009 à 08:02 (CET)

Hors l'introduction, l'article anglophone est meilleur. L'objectif est d'au moins faire mieux. Je le repète, le mieux c'est de faire un brouillon de l'article que vous voulez développer dans une de vos sous-pages. De mon coté, je n'ai pas trop le temps de travailler sur cet article. GLec (d) 8 mars 2009 à 20:45 (CET)

D'accord avec toi, hormis l'introduction, le reste de l'article est bien mieux dévelopé que l'article francophone. Je prépare en ce moment un brouillon, ca se passe ici, il y a pour le moment l'introduction serveur et client , je vais continuer...--Silex6 (d) 8 mars 2009 à 21:01 (CET)

Sourcer l'article

Bonjour. Il serait souhaitable de sourcer davantage l'article. De plus, une section bibliographie serait la bienvenue. GLec (d) 18 mars 2009 à 09:28 (CET)

Relecture

En faisant une relecture globale, j'ai relevé quelques phrases/expressions qu'il faudrait préciser :

• « Le mode pair-à-pair (anglais peer-to-peer ou P2P) est l'opposé du mode client-serveur. » : je ne pense pas car on a bien des clients (les pairs) et des serveurs (serveurs ed2k...). Au lieu d'énoncer une fausse vérité générale (c'est surtout le mot "opposé" qui me gêne), il vaudrait mieux expliquer les différences qu'il existe entre les deux.

n'est-ce pas une confusion entre le partage de fichiers tout court, et le mode pair-à-pair ? si tu parles de eDonkey, c'est un logiciel de partage de fichiers en client-serveur (il y a des clients eDonkey et des serveurs...).--Silex6 (d) 2 novembre 2009 à 12:52 (CET)

C'est surtout le mot "opposé" qui ne va pas : du pair à pair, c'est du client-serveur où les clients sont aussi de serveurs (avec ou sens serveurs centraux). Les deux ne s'opposent pas : le p2p est un client-serveur particulier avec d'autres avantages et d'autres inconvénients. (La définition sur pair-à-pair est d'ailleurs erronée. L'intro de en:Peer-to-peer est plus nuancée à ce sujet : le terme "contrast" y introduit la principale différence entre les deux termes, et non leur opposition/antagonisme.)

Peut-être vaut-il mieux expliquer la différence: à savoir qu'en client/serveur il y a deux ordinateurs et logiciels différents et complémentaires (comme indiqué dans l'article) alors qu'en P2P les logiciels sont identiques sur tout les ordinateurs du réseau P2P.

Ok.

• « Un Network Attached Storage est un appareil clé en main, conçu spécialement comme serveur de fichier. Il existe également des appareils clé en main pour les serveurs d'impression. » : l'expression "clé en main" (l'expression revient aussi plus loin) n'est pas très claire pour un néophyte ; on devrait plutôt dire "prête à l'emploi" ou préciser qu'il y a juste à branche :).

l'expression "clé en main" est surtout utilisée pour parler de voitures. selon le dictionnaire Larousse « se dit de la vente d'un appartement, d'une voiture, etc., prêts à être utilisés dès la livraison ; se dit d'un contrat par lequel la conception, la réalisation, la mise en service d'une entreprise ou d'un complexe industriel incombent à un contractant unique. »[1]. c'est synonyme de "prêt à l'emploi" ou de "brancher, ca marche" (expression que j'apprecie peu depuis qu'elle a été utilisée abusivement par certains éditeurs de logiciels).--Silex6 (d) 2 novembre 2009 à 12:52 (CET)

Je ne savais pas que le terme était dans le langage courant (je l'avais classé dans "terme techniquo-commercial informatique abscon" et "mauvaise traduction de plug and play" :). Tant que tout un chacun peut comprendre, ça me va!

J'ai le sentiment qu'il manque aussi une partie (ou quelques phrases) sur l'auto-hébegement. Romainhk (QTx10) 2 novembre 2009 à 11:51 (CET)

Tu parles ici des logiciels serveurs hébergés sur les ordinateurs de l'éditeur ? ca mérite en effet d'être mentioné.--Silex6 (d) 2 novembre 2009 à 12:52 (CET)

Aussi! À la base, je pensais plus à la possibilité de concevoir soi-même des serveurs, par exemple grâce aux LAMP, aux WAMP..., et d'utiliser sa propre connexion internet pour devenir un émetteur. Romainhk (QTx10) 2 novembre 2009 à 13:59 (CET)

OK, a condition de ne pas tomber dans le guide pratique "HOWTO-monter un serveur soi-même"...--Silex6 (d) 2 novembre 2009 à 19:50 (CET)

Voila, un petit paragraphe en plus. (C'est surtout pour donner des pistes de recherche au lecteur curieux ;) Romainhk (QTx10) 3 novembre 2009 à 10:28 (CET)

Contenu - Déplacé depuis Bon article

Bonjour. je suis etonné du peu de remarques concernant le fond de cet article et l'aspect encyclopédique de celui-ci. Ce qui me laisse à penser que soit l'aspect encyclopédique importe peu pour le label BA, soit aucun votant n'a pris la peine de lire l'article. Je doute vraiment que le contenu de l'article soit pas sujet à commentaire...--Silex6 (d) 17 novembre 2009 à 18:31 (CET)

Salut, j'ai lu rapidement l'article et il me semble quand même pas vraiment complet. Dans un article pareil, j'aurai aimé entendre parler des problématiques que rencontrent les gros serveurs, comme la répartition de charge, les grappes de serveurs, avoir des exemples de serveurs un peu plus "grand public" comme des moteurs de recherches, avoir des liens vers des architectures un peu complexes comme le "cloud computing" (informatique dans les nuages), avoir un historique un peu plus détaillé, par exemple entendre parler des terminaux (X ou pas) qui se contentaient d'afficher et de se connecter, pourquoi pas du "Minitel", des BBS pour le grand public, puis de l'époque ou les applis sont passé sur le poste client (suites office, typiquement) pour voir revenir en force le concept de client serveur avec Internet, les applis webs (webmails par exemple, google maps, google earth qui est une appli client qui va chercher ses données sur des serveurs google, pour ne citer que ça, le traitement de texte en ligne, etc. ), les serveurs d'applis, d'avoir des liens vers les articles correspondants, pour ne parler que de ce qui me vient à l'esprit sur le moment ...

Coté matériel, pourquoi ne pas citer des noms de servers célèbres comme les OS 400 d'IBM, et autres machines avec des temps de disponibilités impressionnant, des redondances de matériel, etc.

On peut aussi parler des problématiques de gestion de la charge que cela entraine : avoir des machines puissantes, des architectures sophistiquées et des logiciels qui tiennent la charge ( Oracle pour la base de donnée typiquement, les problématiques de réplications, de synchronisation de données entre plusieurs serveurs), le cloud computing, les caches pour faire plus techniques, beaucoup de bande passante, suivant les applis.

Pourquoi pas évoquer d'autres architectures, comme les architectures peer to peer qui essayent de s'affranchir des serveurs, par opposition ...

Dans un autre registre, pourquoi ne pas aborder les problématiques de vie privée et, pour l'utilisateur de confier ses données à des serveurs sur lesquels il n'a qu'un contrôle limité

Je suis partis dans tous les sens et il faudrait surement faire le tri dans ce que j'ai dit ...

TomT0m (d) 24 novembre 2009 à 20:20 (CET)

Je fais un peu le tri des sujets avant de répondre:

1. répartition de charge, grappe de serveurs, synchronization entre les serveurs d'une grappe, bande passante
2. moteur de recherche
3. cloud computing (informatique en nuage)
4. histoire avec terminaux, Minitel et BBS, ensuite applications client, puis retour aux applications serveur.
5. noms de serveurs célèbres, comme par exemple IBM OS 400. florilège des capacités et du uptime.
6. serveurs et respect de la sphère privée.
7. peer-to-peer.

D'une facon générale les sujets connexes, qui touchent aux serveurs, sont nombreux. Si je prends l'exemple des grappes et de la répartition de charge, le sujet est mentionné dans la section sur le matériel. Il n'est pas expliqué (c'est pas le sujet de cet article). La mention du cloud computing pourrait être ajoutée dans la section technique et les moteurs de recherche mentionnés parmi les applications web (il y a déja le webmail et le blog).

Concernant l'histoire, j'était parti tout d'abord sur ton idée: les terminaux, puis les applis client, puis retour aux terminaux. J'ai abandonné par manque de sources [2].

La section concernant l'économie est un peu courte. On pourrait y mettre le nom de quelques serveurs célèbres (historiques ou contemporains) avec des chiffres.

Et puis les problèmes liés à la sphère privée sont relatifs aux systèmes d'informations en général, plutôt qu'aux serveurs en particulier, non ?

--Silex6 (d) 25 novembre 2009 à 13:02 (CET)

Je suis pas d'accord au sujet des sujets connexes, la partie sur l'avènement du logiciel libre m'a l'air d'être déplacée et connexe de manière lointaine dans l'article, par rapport à des problématiques plus centrales comme les problèmes techniques posés par l'architecture client/serveur, comme la répartition de charge. Il n'est pas inutile de parler du logiciel libre parce qu'ils sont fortement présents dans les serveurs en général, apache, php, bind et caetera, mais ça peut se dire en deux phrases, ce n'est pas un article sur Unix. L'historique et la mise en contexte doivent permettre d'introduire ses problématiques, sans les détailler. Par exemple, pour la répartition de charge, on peut parler de l'explosion d'Internet et donner des exemples comme Youtube pour faire emblématique, grosses audiences, gros besoins en caculs liés au traitement vidéos, grosses bandes passantes, donc pleins de serveurs et des problèmes de montées en charges, qui sont traîtées par des architectures compliquées de grappes de serveurs. Pas forcément besoin de rentrer dans les détails de l'architecture en questions dans cet article, mais de quoi introduire et renvoyer vers les techniques et les articles correspondants ... C'est ce genre de truc qu'il faudrait faire pour effacer la critique "d'article non rédigé" qui a été faite dans la proposition de BA, je pense. En l'état actuel des choses, ça fait un peu "suite de définitions" qui tombent un peu comme un cheveu sur la soupe, il faut expliquer pourquoi une définition est introduite, sinon on comprends pas forcément à quoi elle sert.

Les problèmes liés à la sphère privée sont dus à l'omniprésence actuelle du web et des applis web, qui fait que de plus en plus de personnes confient des données personnelles à des serveurs distants, facebook, les applis google, les webmails, de manière plus ou moins centralisée. D'une manière générale, la partie sur les serveurs web mériterait d'être étoffée étant donné l'importance qu'ils ont aujourd'hui. la phrase "En réponse à une demande, le serveur peut envoyer un document qui est stocké en tant que fichier dans les mémoire de masse du serveur ou exécuter un traitement puis envoyer le résultat sous forme d'un document. HTTP et HTTPS sont les protocoles des serveurs web et HTML est le format de fichier prévu à cet effet." est un peu simpliste quand on considère des applis comme les wikis ou les applis web comme "google documents" ... D'une part le vocabulaire me semble un peu trop technique, une formulation comme "renvoyer un document préexistant ou en créer un à la volée pour répondre à une demande d'un utilisateur à partir d'informations stockées dans une base de donnée" me semble moins précise mais plus accessible, d'autre part on oublie un peu le côté "participatif" qui fait que les serveurs web d'aujourd'hui ne font pas que servir des documents, ils reçoivent aussi beaucoup d'information, gèrent du contenu utilisateur, voire sont des bouts d'applications complexe, comme les webservice. Actuellement, c'est surtout une suite de phrase sans vrai cohérence qui fait un peu suite de définition.

Toujours en vrac, il ne me semble pas inutile d'évoquer aussi des métiers liés aux serveurs, en particulier l'administration.

On peut aussi évoquer d'autres types de serveurs, comme les serveurs de sauvegardes, les serveurs d'infrastructure comme les serveurs DNS.

Je vais essayer de retravailler un ou deux passage pour commencer TomT0m (d) 3 décembre 2009 à 21:25 (CET)

Je relis cet article avec du recul, 2 ans après l'avoir recyclé, et je suis assez d'accord avec les commentaires ci-dessus. Je le trouve un peu léger et superficiel, a vu de la quantité de sources sur le sujet, notamment dans la bibliographie. J'ai commencé d'étoffer l'article, en particulier les points suivants:

1. L'histoire. Les serveurs c'est un domaine vieux de plus de 30 ans, et bien vivant: BBS, grande mode du client-serveur, puis de l'Internet.
2. Les utilisations. les explications sont un peu sommaire et ne répondent pas à la question "à quoi ca sert ?". Un serveur fournit des services, lesquels ?
3. Les caractéristiques techniques clé des serveurs. Il y a des tout petits et des tout grands. Panorama de l'offre, points communs et différences.
4. Sourcage et qualité du contenu: de nombreuses sources ont été ajoutées à la fin de la rédaction. Le texte ne corresponds pas très bien, la source n'est pas centrée. Il y a de nombreuses sources web - qui ont la vie courte.

--Silex6 (d) 16 septembre 2011 à 12:15 (CEST)

Réf morte

Bonjour, la référence 32 sourçant cette information n'est plus accessible, il faudrait en trouver une pour la remplacer « En 2009, 35 % des serveurs sont équipés avec les systèmes d'exploitation Windows NT, 14 % sont installés avec Linux et 36 % sont installés avec un autre système d'exploitation de la famille Unix. Les parts de Windows NT sur le marché des serveurs sont soutenus par la domination des systèmes d'exploitation Windows sur le marché des ordinateurs clients (plus de 80 % des parts de ce marché)[32]. ». Pamputt ✉ 22 février 2011 à 19:08 (CET)

La référence est toujours accessible via le lien archive. Cependant, je pense qu'il serait nécessaire de la mettre à jour Xavier Combelle (d) 22 février 2011 à 19:17 (CET)