Créer rapidement des sites en local

Un petit article très technique, qui pourra être utile à des développeurs Web qui veulent créer rapidement des sites en local sans se prendre la tête.

Je ne sais pas pour vous, mais j’ai souvent besoin de créer des sites qui me servent à prototyper des développements ou à tester des évolutions sur mon framework. Habituellement, cela se passe en plusieurs étapes :

  1. Je crée une entrée dans le fichier /etc/hosts, pour que le nom de domaine du site pointe sur la machine locale.
  2. Je crée un fichier pour configurer le “virtual host” dans Apache.
  3. Je redémarre Apache.
  4. Enfin, je peux créer le site lui-même.

Ce n’est pas grand-chose à faire, mais multiplié par le nombre de sites, c’est un peu pénible. En plus, quand on veut coder un truc vite fait, on n’a vraiment pas envie de perdre du temps à faire tout ça. En ce qui concerne mes projets personnels, je développe mes “vrais” projets sur un serveur distant ; par contre, je préfère coder les petits trucs rapides en local.

Dans mon entreprise, on a en partie contourné le soucis, mais on continue à créer des fichiers de configuration Apache (on ne fait pas de «projets-kleenex»). Je vais vous expliquer comment je fais pour gérer mes projets personnels.

Nom de domaine

La première chose à faire, c’est de pouvoir facilement se connecter au serveur web du poste local. Si on veut créer un petit site de test, on a envie de pouvoir taper «http://sitedetest.com» dans son navigateur, sans se prendre la tête à modifier le fichier /etc/hosts ou à gérer un serveur DNS.

J’ai donc utilisé le nom de domaine «ordi.org», que je possède depuis un paquet d’années sans rien en faire. J’ai configuré le DNS de ce nom de domaine pour qu’il retourne l’adresse IP 127.0.0.1 (qui correspond toujours à la machine locale, j’espère que je ne vous l’apprend pas), quel que soit le nom de machine demandé. Ainsi, si je saisi «http://sitedetest.ordi.org», «http://site1.pouet.ordi.org» ou «http://site2.pouet.ordi.org», ça me renverra systématiquement vers la machine sur laquelle je suis.

C’est simple, c’est pratique. Vous pouvez l’utiliser si vous voulez. Je ne garantis pas que ce fonctionnement restera ainsi éternellement, mais vu que je l’utilise de cette manière pour mon propre usage, vous pouvez y aller assez sereinement.

La seule chose un peu chiante, c’est lorsque je développe sans être connecté à Internet (sur mon ordinateur portable dans le train, par exemple). Dans ce cas-là, la résolution DNS ne fonctionne pas. Il serait possible de configurer un serveur DNS local − auquel cas choisissez Dnsmasq, qui est bien plus simple et léger que Bind − mais ça reste un peu un gros canon pour écraser une petite mouche. Comme il m’arrive rarement de travailler sur beaucoup de sites en parallèle, je préfère encore modifier temporairement le fichier /etc/hosts…

Configuration Apache

Les «virtual hosts dynamiques» sont des petites merveilles qui simplifient la vie comme pas possible. À une époque, je créais un fichier de configuration pour chaque nouveau site que je développais.

Voici un exemple de fichier /etc/apache2/sites-available/default comme on peut en trouver sur une distribution Linux Debian/Ubuntu standard, modifié par mes soins pour permettre le chargement automatique de tous les sites locaux que l’on souhaite :

UseCanonicalName Off
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon
VirtualDocumentRoot /opt/http/%0/www

(suivant les outils utilisés − notamment le framework − vous aurez peut-être besoin d’ajouter des directives supplémentaires)

Hop, juste 4 petites lignes et ça marche. Et encore, il y a 2 lignes qui sont là pour configurer le fichier de log, on pourrait éventuellement s’en passer (ça ne serait pas une bonne idée, mais c’est possible).

Pour chaque connexion locale, le serveur Apache ira chercher dans le répertoire spécifié par la directive «VirtualDocumentRoot», en remplaçant la chaîne «%0» par le virtual host demandé.
Si on prend l’exemple du site «sitedetest.ordi.org», il faudra créer un répertoire /opt/http/sitedetest.ordi.org qui devra contenir un sous-répertoire www qui sera la racine du site.

Le tout combiné me permet, pour chaque nouveau site, d’avoir simplement à créer deux répertoires. Et comme j’ai des scripts qui me permettent de générer automatiquement l’arborescence des projets basés sur mon framework, la création d’un site local se résume à l’exécution d’une commande.

Gestion de cache et péremption des données

Je suis actuellement en train de travailler sur une couche d’abstraction de données (pour améliorer celle de mon framework afin de la rendre plus transparente).
J’ai buté sur un problème assez classique, que je vais partager avec vous car cela pourrait vous intéresser.

Ma couche d’accès aux données sert habituellement à faire des requêtes sur une base SQL. Afin de réduire le nombre de requêtes réellement effectuées, et d’améliorer les performances, cette couche a la capacité de mettre les résultats des requêtes en cache. Ce cache est basé sur Memcache, qui garde les données en RAM pendant une durée maximale définie, et la bibliothèque PHP qui y accède sérialise les données sans qu’on ait à s’en préoccuper.

Mais comment stocker ces données en cache ? Memcache permet d’enregistrer une variable en la nommant par une chaîne de caractère.
Ainsi, si je vais récupérer le contenu d’un enregistrement d’une table à partir de sa clé primaire, je commence par créer une chaîne constituée de la sorte :

__dao:nom_de_la_base:nom_de_la_table:get:clé_primaire

Ensuite, je vais regarder si j’ai une donnée en cache disponible avec ce nom. Si ce n’est pas le cas, je fais la requête, stocke son résultat en cache puis le retourne.

(bon, vous aurez compris que lorsque je parle à la première personne, c’est pour me mettre à la place du code ; c’est bizarre comme habitude, mais on fait tous ça, hein)

Mais dans le cas où on fait une modification sur les données de la table, il est impossible de savoir à l’avance si les données préalablement récupérées sont toujours valables ou non. La démarche la plus logique est donc de vouloir tout invalider d’un coup. On se heurte alors à une limitation de Memcache ; il est impossible de récupérer, modifier ou effacer plusieurs variables de manière groupée. C’est dommage, parce qu’il serait très pratique de pouvoir écrire quelque chose du genre :

$cache->deleteFromPrefix('__dao:nom_de_la_base:nom_de_table');

Si on prend le temps de réfléchir, il n’existe pas des milliards de manières de solutionner ça. En fait, je vois trois grandes possibilités.

Tricher pour contourner le problème

Le plus simple, c’est déjà de faire ce qu’il faut pour ne pas avoir à gérer l’expiration des données. La plupart du temps, on peut se permettre d’afficher des données qui ne soient pas complètement à jour. Par contre, sur un site à très fort trafic, il reste important de ne pas frapper la base de données à chaque affichage de page. Continuer la lecture de « Gestion de cache et péremption des données »

INI vs JSON vs XML

Dans la plupart des applications, on a besoin d’enregistrer des informations. Au minimum, il faut un fichier de configuration, pour savoir comment se connecter à la base de données qui stockera le reste des infos. Dans le cas d’applications sans base de données, tout sera enregistré dans des fichiers.

À une époque, on écrivait des fichiers binaires, qui correspondaient à de simples «dump» de structures (ceux qui ont fait du C me comprendront). C’était très performant, tant en lecture qu’en écriture, mais posait de nombreux soucis concernant la gestion des chaînes de caractères et l’utilisation des fichiers sur des architectures différentes (avec les problèmes de boutisme qui en résultent).

À la fin des années 90, le XML a fait son apparition et s’est vite répandu. Cela semblait être une solution couvrant la plupart des besoins d’un manière élégante et générale. Un même parseur pouvant lire n’importe quel fichier XML, on pouvait abandonner les parseurs spécifiques à chaque application. La consommation supplémentaire en temps de traitement et en espace disque ont été en partie gommés par l’augmentation de puissance des machines et par la compression des fichiers XML (comme OpenOffice, par exemple, dont les documents sont des fichiers ZIP contenant des fichiers XML).

Avec le temps − et après la période d’engouement maladif pour le XML − on s’est toutefois rendu compte des imperfections du XML, Et que s’il reste très pertinents dans certains cas, principalement lorsqu’il faut pouvoir valider les documents en fonction d’une DTD ou d’un schéma, il ne s’agissait peut-être pas d’un format miraculeux à utiliser systématiquement. Entre autre, le fantasme du parseur universel s’est éteint quand on s’est rendu compte que la logique avait été en grande partie déportée vers l’application qui fait appel au parseur.

Ainsi, un certain nombre d’alternatives sont apparues, toutes n’ont pas survécu. Si le format YAML a ses partisans, le format JSON a réussi à rassembler un nombre massif d’utilisateurs grâce à sa syntaxe assez simple, relativement bien lisible par un être humain, et qui ne bouleversait pas complètement les habitudes (format natif en Javascript, syntaxe très similaire à l’écriture de listes et de tableaux associatifs en Perl). Pourtant, il existe un autre format, plus simple, plus limité fonctionnellement, très bien connu, qui mérite qu’on s’y attarde, c’est le format INI.

Il y a une sorte de snobisme amusant chez les informaticiens quand on parle de ce format. Comme si ses limitations (principalement, le fait de ne pas pouvoir créer plus de 2 niveaux d’imbrication) en faisaient de facto un mauvais choix quelque soit la situation. Mais un format plus simple voulant sûrement dire qu’il est plus facile à lire et interpréter, donc plus rapide à utiliser pour un programme informatique, je m’étais posé quelques questions il y a des ça plusieurs années.
Pour en avoir le cœur net, j’ai voulu vérifier le temps de lecture (je pars du principe qu’un fichier est lu bien plus souvent qu’il n’est écrit) en PHP d’un fichier INI, un fichier JSON et un fichier XML équivalents.

Le contenu du fichier INI :
trululu=pouet
toto=titi

Le fichier JSON :
{
    "trululu": "pouet",
    "toto": "titi"
}

Le fichier XML :
<?xml version="1.0"?>
<data>
    <trululu>pouet</trululu>
    <toto>titi</toto>
</data>

J’ai utilisé les fonctions natives de PHP les plus simples pour lire ces fichiers : parse_ini_file(), json_decode() et simplexml_load_file(). J’ai bouclé sur cinquante mille itérations pour chacun, et j’ai chronométré le temps de traitement.

Le résultat est très intéressant :

  • 1,731576 seconde pour le fichier INI
  • 2,077062 secondes pour le fichier JSON
  • 3,821663 secondes pour le fichier XML

On peut voir qu’il y a un rapport du simple au double entre le fichier INI et le fichier XML. Par contre, la différence est plutôt minime entre le fichier INI et le fichier JSON. Il faut bien garder en tête que la différence augmente avec la complexité du fichier à lire (de même que la taille du fichier).

Ce test n’est évidemment pas représentatif de l’utilisation classique d’un fichier de stockage de données. Mais il donne quand même un éclairage intéressant. Cela a guidé mon choix de l’utilisation de fichiers INI pour la configuration et le stockage des méta-données dans mon système de fichiers réseau FineFS. Le système pouvant se révélé gourmand en entrées-sorties, il fallait privilégier la méthode la plus efficace. Par contre, le framework que j’ai développé dans mon entreprise avait au début des fichiers de configuration au format INI ; mais des besoins de plus grande souplesse se sont fait sentir avec le temps, et nous sommes passés à un format JSON. Par contre il n’y aurait aucune bonne raison pour migrer vers du XML.

Les joies des problèmes IT

Je vais écrire un billet un peu inhabituel, aujourd’hui. Je dis souvent qu’il ne faut jamais compter sur la fiabilité des ordinateurs. C’est tellement vrai que depuis une semaine, j’enchaîne les problèmes techniques sur mes serveurs, les uns après les autres. Aucune relation entre les problèmes, ce sont juste de fâcheux concours de circonstance qui nous font perdre des dizaines de milliers d’euros de chiffre d’affaire.

Reprenons depuis le début. Les serveur de mon entreprise sont loués chez une entreprise française très connue, leader européen de l’hébergement. Nous avons actuellement 5 serveur chez eux, sachant qu’on en a eu jusqu’à 7 en même temps. Ce n’est pas une infrastructure de folie, mais le coût tourne quand même autour du millier d’euros mensuel.

Historique

Avant de parler des problèmes qui s’enquillent depuis une semaine, voici un petit récapitulatif rapide des problèmes rencontrés ces 2 dernières années (je ne liste là que les problèmes techniques pour lesquels l’hébergeur a fait des erreurs ; je ne liste pas les quelques problèmes qui ont été résolus en moins de 2 heures) :

22 décembre 2008
Problème disque dur.
Retards de communication et mauvaise prise en charge par l’hébergeur.
18h30 d’interruption de service.
15 jours de location serveur offerts.

26 mai 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
10 heures d’interruption de service.
10 jours de location serveur offerts.

07 juillet 2010
Problème disque dur.
Mauvais diagnostic technique par l’hébergeur.
8 heures d’interruption de service.
14 jours de location serveur offerts.

25 novembre 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
4 jours d’indisponibilité de service.
Un mois de location serveur offert.

Dans tous ces cas, l’hébergeur garantissait un délai de rétablissement de 4 heures maximum. C’est la raison pour laquelle des pénalités de retard furent appliquées.
Pour la petite histoire, j’ai aussi un serveur personnel chez cet hébergeur. Et il a aussi connu 2 changements de disques et un changement de carte mère dans le même intervalle.

L’emmerdement maximal

Juste pour montrer comment les choses peuvent s’additionner pour provoquer des interruptions de service à répétition, voici ce qui s’est passé ces derniers jours :

Continuer la lecture de « Les joies des problèmes IT »

Plus loin que la simplicité : la rusticité

J’ai déjà parlé du concept de simplicité sur ce blog. J’espère que tout le monde est convaincu des avantages que cela procure à tous les niveaux :

  • Une interface simple sera plus facile à comprendre et à utiliser ; elle sera plus ergonomique.
  • Un code simple sera plus facile à corriger et à faire évoluer ; il sera plus facile à maintenir.
  • Une procédure ou une méthode sera adoptée d’autant plus rapidement qu’elle sera simple à appréhender et facile à mémoriser.

Nous sommes d’accord, le «simple», c’est bien. Et comme d’habitude, c’est aussi le moment de dire que le «simpliste», ce n’est pas bien. Faire quelque chose de simpliste, c’est lorsqu’on recherche la simplicité aveugle ; quand on confond «en faire moins» avec «en faire le moins». Il faut parfois complexifier un peu un programme pour en simplifier l’ergonomie. Ou faire des concessions sur la simplicité d’une procédure si cela peut en augmenter l’efficacité.

Bref. Ce dont je veux vous parler aujourd’hui, c’est du concept de rusticité.

L’un des fondements du travail d’informaticien, c’est d’aimer la technologie, de se passionner pour l’avant-garde du high-tech, de chercher à connaître les technos du futur. C’est ainsi qu’on cherchera à mettre en œuvre des concepts ou des briques logicielles (ou matérielles) que nous ne maîtrisons pas forcément, pour le plaisir d’apprendre à les utiliser. Souvenez-vous ce que je disais sur la R&D : il ne faut pas confondre développement et veille technologique.

Sans aller jusqu’à faire de la recherche alors qu’on devrait faire du développement, on peut conduire nos choix en se laissant porter par des effets de mode. Quelle est la techno «hype» du moment ? Quels sont les derniers «buzzwords» à connaître ?

En entreprise, les facteurs qui conduisent à un choix technologique sont multiples. La stabilité et la pérennité sont très importants. Ils le sont souvent plus que la performance ou le coût.
Ajoutez cela à la simplicité, et vous aboutissez à la «rusticité».

Une techno rustique, c’est quoi ?

Attention à ne pas comprendre de travers ce que j’essaye d’expliquer. Je ne suis pas en train de dire qu’il faut systématiquement utiliser des technologies antédiluviennes, au nom de leur rusticité. Moi je parle de “rusticité high-tech”, si je puis dire 🙂

Prenons un exemple au sujet des langages de programmation :

  1. Coder un site web en Fortran, ce n’est pas rustique, c’est débile. Votre site sera difficile à maintenir, vous aurez du mal à trouver des développeurs Web compétents dans ce langage, vous n’aurez aucun gain de performance par rapport à d’autres langages, et il vous manquera l’accès à un certain nombre de librairies très utiles.
  2. Par contre, une application de calcul scientifique distribuée sur un cluster pourra être codée en Fortran. C’est un choix très répandu : C’est un langage sans allocation dynamique, donc qui s’optimise très bien sur les architectures distribuées ; de nombreux scientifiques continuent à maintenir du code écrit en Fortran il y a 30 ans, sans avoir objectivement besoin de changer de langage ; réutiliser ce code est une bonne idée.

Un exemple concernant l’innovation fonctionnelle :

Continuer la lecture de « Plus loin que la simplicité : la rusticité »

FineFS, système de fichiers redondé

J’ai lancé depuis quelques temps un projet dans mon entreprise, que nous venons de publier sous licence libre. Il s’agit d’un système de fichiers répliqué du nom de FineFS.

Je vais en parler ici parce qu’il s’agit d’un projet intéressant d’un point de vue technique, sur lequel les esprits imaginatifs peuvent venir s’éclater avec nous. Mais aussi parce qu’à travers ce projet, je veux vous présenter l’univers des systèmes répartis/distribués/redondés et des bases de données à très haute disponibilité – que tout directeur technique doit connaître un minimum.

Présentation du projet

Le but de ce projet est de faciliter la création de cluster-disque. Lorsque vous avez plusieurs serveurs qui doivent accéder aux mêmes fichiers, il est toujours délicat de mettre en place une architecture satisfaisante sans dépenser des sommes folles. Et pourtant, la moindre infrastructure Web présente plusieurs serveurs frontaux, qui doivent délivrer des contenus (images, vidéos, musiques) communs. Sans compter que ces différents serveurs doivent aussi pouvoir enregistrer de nouveaux fichiers, qui doivent être accessibles à toutes les autres machines.

Il existe plusieurs moyens de mettre des fichiers à dispositions de plusieurs serveurs :

  • Installer un NAS, c’est-à-dire un serveur de fichiers. Mais si ce serveur tombe en panne, plus aucun fichier n’est accessible.
  • Installer un SAN, qui prend souvent la forme d’une baie de stockage redondée. Mais les prix de ce genre d’installation grimpent très vite.
  • Utiliser un service externe, comme Amazon S3, qui prend en charge les aspects complexes de la gestion des fichiers. C’est souvent une solution satisfaisante pour du Web, mais qui peut induire des latences dans les accès aux fichiers, et des coûts inutiles.
  • Mettre en place un système de fichiers réparti, redondé et/ou distribué.

C’est dans cette dernière catégorie que se place FineFS. Il existe déjà des solutions qui s’emploient à résoudre ce besoin, qu’on peut répartir en 5 groupes :

Continuer la lecture de « FineFS, système de fichiers redondé »

Gestion de sources, versions de logiciels

Lorsqu’on développe un logiciel, il est absolument nécessaire d’utiliser un outil de gestion de sources. Évidemment, il serait possible de stocker ses fichiers dans un répertoire. Mais si vous voulez travailler sérieusement, vous aurez besoin de stocker les différentes versions de vos sources, pour suivre leur évolution au fil du temps ; et si vous travaillez à plusieurs sur le même projet, cela devient impossible.

Les logiciels de gestion de sources permettent à plusieurs personnes de travailler sur les mêmes fichiers, chacun dans leur coin, puis de tout rassembler pour obtenir une version continuellement à jour des sources. Ils apportent des fonctions permettant de définir des versions globales. Il existe un grand nombre de ces systèmes :

  • Les ancêtres RCS et CVS ont laissé la place à Subversion, qui offre des fonctionnalités supplémentaires bien appréciables. Ce sont des systèmes centralisés faciles à appréhender et à installer, et sont sous licence libre.
  • De nouveaux système sont apparus, basés sur un modèle décentralisé. Parmi ceux-ci, ont peut noter que les plus connus dans le monde de l’open-source sont Bazaar (sponsorisé par Canonical, à l’origine de la distribution Linux Ubuntu), Git (utilisé pour le noyau Linux) et Mercurial.
  • Du côté des logiciels propriétaires, les plus connus sont Visual SourceSafe de Microsoft et BitKeeper (qui a été utilisé pour le noyau Linux jusqu’en 2005).

Je vais vous présenter l’utilisation de ces outils, en utilisant l’exemple de Subversion (SVN en abrégé) car c’est le système de plus répandu et celui que j’utilise ; mais ces concepts sont toujours valables.

Principes généraux

Gestion basique

A la base, les sources d’un projet sont disponibles sur la branche principale (trunk). Les développeurs y récupèrent les sources (checkout) sur leur propre environnement de travail, et y ajoutent leurs versions modifiées (commit).

 

Continuer la lecture de « Gestion de sources, versions de logiciels »

Pas d’intégrisme technologique

J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.

On a tous entendu ce genre de réflexions :

  • « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
  • « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
  • « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
  • « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
  • « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
  • « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
  • « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.

On peut apporter des réponses intelligentes à toutes ces remarques :

  • Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
  • Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
  • Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
  • Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
  • La vraie question est plutôt « Pourquoi utiliser Windows ? ».
  • Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
  • Vous imaginez que Google tourne sur une seule machine ?

Faire un choix structurant

Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.

Continuer la lecture de « Pas d’intégrisme technologique »

Prestation interne ou externe ?

Quand on doit choisir un outil informatique, l’une des questions que l’on doit se poser assez rapidement concerne le choix entre un outil interne à l’entreprise ou l’utilisation d’une prestation externe.

Quand je parle d’outil interne, je ne parle pas de développement réalisé en interne (même si ce cas existe bel et bien), mais des logiciels que l’on peut installer sur des machines propres à l’entreprise. Les prestations externes concernent les services qui sont disponibles à distance, souvent en SaaS (software as a service). Cela peut s’appliquer à un grand nombre de choses :

  • La gestion des emails. Votre entreprise doit-elle posséder son propre serveur SMTP, ou bien allez-vous passer par GMail/Hotmail/YahooMail ?
  • La gestion de document. Faut-il installer un serveur de fichiers interne, ou pouvez-vous vous reposer sur Google Doc/Zoho Docs ?
  • La gestion de projet. Est-il préférable d’utiliser une solution autonome, ou une plate-forme collaborative hébergée chez un prestataire ?

La prestation externe

L’utilisation d’un prestataire extérieur offre plusieurs aspects très pratiques :

  • Le service est disponible de partout (dans le cas de logiciels disponibles sur le Web). C’est très utile quand on a des collaborateurs disséminés géographiquement.
  • Le coût est limité. Les services d’email sont gratuits pour la plupart, et les offres logicielles payantes (gestion de projet, CRM, …) coûtent habituellement moins cher que la location d’un serveur.
  • La qualité du service est très bonne. Ces prestataires doivent gérer un très grand nombre d’utilisateurs, et mettent en place des architectures matérielles et logicielles prévues pour tenir la charge. Des équipes administrent ces services 24h/24, ce qui évite d’avoir à le faire soi-même.

L’installation interne

D’un autre côté, l’installation de logiciels en interne possède aussi de gros avantages :

Continuer la lecture de « Prestation interne ou externe ? »