<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Quatrecentquatre &#187; programmation</title>
	<atom:link href="http://blog.quatrecentquatre.com/tag/programmation/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.quatrecentquatre.com</link>
	<description>3437 St-Laurent, Montréal, Québec, H2X 2T6, / Téléphone : 514-303-6810</description>
	<lastBuildDate>Mon, 05 Jul 2010 20:59:49 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Système de gestion de contenu, plait-îl ?</title>
		<link>http://blog.quatrecentquatre.com/2009/05/19/systeme-de-gestion-de-contenu-plait-il/</link>
		<comments>http://blog.quatrecentquatre.com/2009/05/19/systeme-de-gestion-de-contenu-plait-il/#comments</comments>
		<pubDate>Wed, 20 May 2009 01:24:22 +0000</pubDate>
		<dc:creator>Jocelyn</dc:creator>
				<category><![CDATA[CMS]]></category>
		<category><![CDATA[Développement]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[framework]]></category>
		<category><![CDATA[gestionnaire de contenu]]></category>
		<category><![CDATA[programmation]]></category>

		<guid isPermaLink="false">http://blog.quatrecentquatre.com/?p=117</guid>
		<description><![CDATA[
Vers la fin des années 90, les système de gestion de contenu ont débuté leur ascension vers la popularité pour tous les sites de petite et moyenne envergure. Les boîtes de production interactive voulaient vendre des sites clef en main. Pour que le client puisse ainsi gérer entièrement sont site comme bon lui semble. Nous [...]]]></description>
			<content:encoded><![CDATA[<p><!--[if gte mso 10]><br />
<mce:style><!   /* Style Definitions */  table.MsoNormalTable 	{mso-style-name:"Table Normal"; 	mso-tstyle-rowband-size:0; 	mso-tstyle-colband-size:0; 	mso-style-noshow:yes; 	mso-style-priority:99; 	mso-style-qformat:yes; 	mso-style-parent:""; 	mso-padding-alt:0cm 5.4pt 0cm 5.4pt; 	mso-para-margin-top:0cm; 	mso-para-margin-right:0cm; 	mso-para-margin-bottom:10.0pt; 	mso-para-margin-left:0cm; 	line-height:115%; 	mso-pagination:widow-orphan; 	font-size:11.0pt; 	font-family:"Calibri","sans-serif"; 	mso-ascii-font-family:Calibri; 	mso-ascii-theme-font:minor-latin; 	mso-fareast-font-family:"Times New Roman"; 	mso-fareast-theme-font:minor-fareast; 	mso-hansi-font-family:Calibri; 	mso-hansi-theme-font:minor-latin;} --></p>
<p>Vers la fin des années 90, les <a href="http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_contenu" target="_blank">système de gestion de contenu</a> ont débuté leur ascension vers la popularité pour tous les sites de petite et moyenne envergure. Les boîtes de production interactive voulaient vendre des sites clef en main. Pour que le client puisse ainsi gérer entièrement sont site comme bon lui semble. Nous avons donc vu au cours des 15 dernières années, dans le cadre de notre travail, des système de gestion de contenu mal fait qui rendait le travail de mise à jours des sites ardu et pénible, et d'autre qui au contraire répondait très bien aux besoins mais qui avec la progression des technologies (intégration Web valide, <a href="http://fr.wikipedia.org/wiki/Web_s%C3%A9mantique" target="_blank">sémantique</a>, dynamisation avec JavaScript, réseaux sociaux) sont maintenant désuets. Nous avons ensuite vu l'émergence des système de gestion de contenu "<a href="http://fr.wikipedia.org/wiki/Open_Source" target="_blank">libre de droit</a>" (<a href="http://typo3.com/" target="_blank">Typo3</a>, <a href="http://drupal.org/" target="_blank">Drupal</a>, <a href="http://www.dotnetnuke.com/" target="_blank">DotNetNuke</a>, etc.) en grand nombre pour le  bonheur des clients moins fortunés. Une solution viable, solide, et robuste (tout dépendant du gestionnaire choisi) à la porté de tous ou presque.</p>
<p>Qu'en est-il maintenant des système de gestion de contenu ? En tant que client ou personne ayant besoin des fonctions d'un système de gestion de contenu, comment choisir la meilleure option pour nos besoin ? Est-ce que le client a réellement besoin d'un système de gestion de contenu ? Est-ce vraiment la meilleur solution pour mon site / application ? La réponse devrait être simple mais malheureusement elle ne l'est pas. Il n'existe aucune réponse parfaite qui saura répondre à tout les besoins que ce soit d'un système de gestion de contenu hyper simple au plus complexe. Pour faire un choix éclairé et qui correspond vraiment à nos besoins, je crois qu'il est important de décrire exactement les options qui s'offrent à un client pour les choix de développement d'un site ou d'une application avec système de gestion de contenu.</p>
<p>Il n'existe malheureusement aucune réponse généralisée qui permet de choisir une solution spécifique qui répondra à tous les cas de figures. À chaque projet sa solution. La meilleure option pour un projet donnée n'est pas nécessairement souhaitable pour un autre projet.</p>
<p><strong>Développement sur mesure<br />
</strong>Il est parfois souhaitable dans certain cas de figure, d'y aller d'une solution complètement sur mesure. On prend bien note des besoins de gestion de contenu du client et on implémente un système de gestion de contenu qui réponds exactement à ces besoins. Cette solution est optimale dans le cas de projet spécial qui nécessite une grande liberté au niveau de la logique de site ou d'application ainsi qu'au niveau graphique. L'utilisation plus ou moins intensive de "Flash" dans un site ou une application implique souvent le développement sur mesure d'un système de gestion de contenu car les système existant (pas tous mais la majorité) ont de la difficulté à bien gérer le "Flash".</p>
<p><em>Avantage<br />
</em></p>
<ul>
<li>Grande liberté au niveau de la conception de l'application et du graphisme.</li>
<li>Permet d'intégrer des fonctionnalités plus complexes sans contourner un système limitatif.</li>
<li>Meilleure gestion de l'intégration des fonctionnalités des réseaux sociaux (<a href="http://www.twitter.com" target="_blank">Twitter</a>, <a href="http://www.facebook.com" target="_blank">Facebook</a>, etc.)</li>
<li>Le système peut être mieux prévu pour une future expansion des fonctionnalités.</li>
<li>Permet d'optimiser les performances du site ou de l'application de façon spécifique.</li>
<li>Gestion optimale de la sécurité de l'application (selon le niveau requis)</li>
</ul>
<p><em>Inconvénient</em></p>
<ul>
<li>Temps et coûts de développement majoritairement plus élevés.</li>
<li>Système fermé et donc connu seulement du développeur ou de l'entreprise réalisant le projet (peut devenir problématique si les personnes responsables ne sont plus disponibles pour l'expansion du système).</li>
<li>On réinvente la roue pour la majorité des fonctionnalités déjà écrite et utilisé par des milliers d'utilisateurs.</li>
</ul>
<p><strong>Développement sur mesure avec "<a href="http://fr.wikipedia.org/wiki/Framework" target="_blank">framework</a>"<br />
</strong>On utilise exactement la même démarche mentionné dans le développement sur mesure mais cette fois-ci au lieu d'effectuer le développement avec ses propres librairies, on utilise des "framework" préférablement "libre de droit" (<a href="http://codeigniter.com/" target="_blank">Code Igniter</a>, <a href="http://cakephp.org/" target="_blank">CakePHP</a>, <a href="http://www.djangoproject.com/" target="_blank">Django</a>, <a href="http://rubyonrails.org/" target="_blank">Rails</a>) comme base au développement du système de gestion de contenu. Ainsi, selon le "framework" utilisé on ne s'oblige pas a réinventer la roue pour développer les opérations de base d'un site ou d'une application Web.</p>
<p><em>Avantage<br />
</em></p>
<ul>
<li>Grande liberté au niveau de la conception de l'application et du graphisme.</li>
<li>Permet d'intégrer des fonctionnalités plus complexes sans contourner un système limitatif.</li>
<li>Meilleure gestion de l'intégration des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.)</li>
<li>Tirer profit d'une base d'usager ayant développé des fonctions similaires avec le même "framework".</li>
<li>Permet au client de passer le flambeau du développement à d'autre développeur ou entreprise qui maîtrise ce "framework".</li>
<li>Permet d'optimiser les performances du site ou de l'application de façon spécifique avec les outils du "framework".</li>
<li>Gestion optimale de la sécurité de l'application (selon le niveau requis)</li>
</ul>
<p><em>Inconvénient</em></p>
<ul>
<li>Temps et coûts de développement majoritairement plus élevés.</li>
<li>Système semi-fermé qui contient une bonne partie de développement effectué par le développeur ou l'entreprise qui  a produit le site ou l'application.</li>
<li>On réinvente la roue pour une partie des fonctionnalités  déjà écrite et utilisé par des milliers d'utilisateurs.</li>
</ul>
<p><strong>Système de gestion de contenu propriétaire<br />
</strong>Développer par des entreprises ou des développeurs (<a href="http://expressionengine.com/" target="_blank">Expression Engine</a>, <a href="http://www.k3media.com/1/applications_web_php" target="_blank">K3 Soft</a>) qui veulent généraliser les opérations courantes d'un système de gestion de contenu et ensuite revendre leur solution pour tirer profit de leur temps de développement et ainsi offrir des solutions clé en mains. Ces solutions répondent aux besoins typiques généralisés pour la pluspart des applications ou site : gestion des pages, gestion du contenu textuel, gestion des menus, gestions des éléments médias, gestions du style graphique des pages, forum, envoie de courriel de masse, wiki, blog, etc... Les prix vont souvent varier selon l'entreprise et les fonctions requisent.</p>
<p><em>Avantage<br />
</em></p>
<ul>
<li>Prêt à utiliser directement après l'installation / configuration.</li>
<li>Facilite les opérations de gestion de contenu typique.</li>
<li>Support de l'entreprise pour l'utilisation et les problèmes avec le produit.</li>
<li>Temps de développement et coût réduit, seulement l'intégration du graphisme est à faire.</li>
</ul>
<p><em>Inconvénient</em></p>
<ul>
<li>Selon les systèmes de gestion de contenu, il y a limitation au niveau graphique pour respecter les guides du système.</li>
<li>Selon le système, difficile voir impossible d'implémenter des fonctionnalités qui sortent des généralités implémenter par celui-ci. (lorsque c'est possible, devient souvent plus long à implémenter que pour une solution sur mesure).</li>
<li>Compte tenu du nombre de personnes qui supporte le développement du système, tendance à être désuet après 1 ou 2 années.</li>
<li>Difficile d'optimiser les performances de l'application ou du site si le site ou l'application éprouve des problèmes de performances.</li>
<li>Outre l'entreprise ou le développeur vendeur du système, personne ne connait le système en place. (peut devenir problématique si les personnes responsables ne sont plus disponibles pour l'expansion du système).</li>
<li>Gestion souvent inexistante des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.).</li>
</ul>
<p><strong>Système de gestion de contenu "libre de droits"<br />
</strong>Ces systèmes utilisent exactement la même approche qu'au point précédant mais cette fois-ci le développement est effectué par la communauté. Ont applique encore une fois une généralisation des fonctionnalités requisent par un système de gestion de contenu . Les systèmes sont donc développer par des milliers de développeur qui tente au fil du temps de développer le meilleur système possible.</p>
<p><em>Avantage</em></p>
<ul>
<li>Prêt à utiliser directement après l'installation / configuration.</li>
<li>Facilite les opérations de gestion de contenu typique.</li>
<li>Tirer profit d'une base d'usager utilisant déjà ce système, une communauté active autour du produit.</li>
<li>Permet au client de passer le flambeau du développement à d'autre développeur ou entreprise qui maîtrise ce système de gestion de contenu.</li>
<li>Temps de développement et coût réduit, seulement l'intégration du graphisme est à faire.</li>
<li>Tirer profit des extensions du système développé par la communauté pour des fonctionnalités qui sortent du cadre générique du système de gestion de contenu.</li>
<li>Système testé par des milliers d'utilisateurs ce qui donne majoritairement un produit robuste et stable.</li>
</ul>
<p><em>Inconvénient</em></p>
<ul>
<li>Selon les systèmes de gestion de contenu, il y a limitation au niveau graphique pour respecter les guides du système.</li>
<li>Selon le système, il est légèrement plus long d'implémenter des fonctionnalités qui sortent des généralités implémenté par celui-ci. (lorsque cette fonctionnalité n'est pas disponible dans la communauté).</li>
<li>Difficile d'optimiser les performances de l'application ou du site si le site ou l'application éprouve des problèmes de performances.</li>
<li>Gestion souvent inexistante des fonctionnalités des réseaux sociaux (Twitter, Facebook, etc.). Il y a cependant amélioration de ce côté.</li>
</ul>
<p>Chacune des solutions comporte ses avantages et ses inconvénients. Il est donc important d'évaluer la meilleure solution en tenant compte premièrement du budget pour le site ou l'application, et ensuite déterminer exactement les fonctionnalités requises. Ensuite, une personne qualifiée pourra vous diriger dans la bonne voie pour tirer maximum à court et long terme de votre solution. Il n'existe pas de solution parfaite, seulement des solutions adaptées.</p>
<p><strong></strong></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.quatrecentquatre.com/2009/05/19/systeme-de-gestion-de-contenu-plait-il/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Comment répondre à la demande</title>
		<link>http://blog.quatrecentquatre.com/2008/12/08/comment-repondre-a-la-demande/</link>
		<comments>http://blog.quatrecentquatre.com/2008/12/08/comment-repondre-a-la-demande/#comments</comments>
		<pubDate>Tue, 09 Dec 2008 02:44:50 +0000</pubDate>
		<dc:creator>Jocelyn</dc:creator>
				<category><![CDATA[Développement]]></category>
		<category><![CDATA[Nouveauté]]></category>
		<category><![CDATA[cloud computing]]></category>
		<category><![CDATA[hébergement]]></category>
		<category><![CDATA[programmation]]></category>
		<category><![CDATA[serveur]]></category>

		<guid isPermaLink="false">http://blog.quatrecentquatre.com/?p=82</guid>
		<description><![CDATA[Dans tout développement d'application interactive, de site web, de microsite, une évaluation sommaire de l'achalandage sur le dit site doit être faîte pour estimer à l'avance le genre de déploiement serveur qui sera nécessaire pour palier à la demande. Avec la nouvelle réalité des réseaux sociaux et du caractère virale de certaines applications ou microsite, [...]]]></description>
			<content:encoded><![CDATA[<p><!--[endif]--><span lang="FR-CA">Dans tout développement d'application interactive, de site web, de microsite, une évaluation sommaire de l'achalandage sur le dit site doit être faîte pour estimer à l'avance le genre de déploiement serveur qui sera nécessaire pour palier à la demande. Avec la nouvelle réalité des réseaux sociaux et du caractère virale de certaines applications ou microsite, il est extrêmement difficile de prédire avec exactitude l'achalandage. Malheureusement, dans certain cas et pour certain serveur, une différence de 2 000 usagers à l'heure dans les périodes de pointe peut signifier la différence entre un serveur bien portant et un serveur avec la langue par terre.</span><span lang="FR-CA">Tout dépendant du type d'application (application avec usage extrême de la base de données, application plutôt statique, application avec utilisation extrême du vidéo) il est souvent difficile de s'en sortir pour les compagnies sans débourser une bonne somme d'argent en serveur balancé ou encore en serveur de "streaming".</span></p>
<p><span lang="FR-CA">Alors quoi faire pour s'en sortir sans briser son cochon ? Pour être sûrs de répondre à la demande tant au niveau de la bande passante que des cycles de processeurs nécessaire pour répondre aux requêtes incessantes de tout ces utilisateurs en besoin de navigation.</span></p>
<p><span lang="FR-CA">Il existe plusieurs options. Tout d'abord nous pouvons toujours confier notre produit entre les mains de services d'hébergement mutualisé ou encore de serveurs dédiés (par exemple avec </span><a title="iWeb Hébergement" href="http://fr.iweb.com/" target="_blank"><span lang="FR-CA">iweb</span></a><span lang="FR-CA"> et </span><a title="1 and 1" href="http://order.1and1.com/xml/order/Home;jsessionid=86C3BD107166677B9EDF924F5D4A14B4.TC60b?__reuse=1228787279203" target="_blank"><span lang="FR-CA">1and1</span></a><span lang="FR-CA">)  si on pense que l'achalandage ne requiert aucune infrastructure serveur faramineuse et que la demande en bande passante ne sera pas exhaustive.</span></p>
<p><span lang="FR-CA">Si notre application utilise la vidéo de façon intensive, ce qui souvent est problématique dans le cas d'achalandage élevé sur des serveurs mutualisé, il y a toujours l'option de placer les vidéos sur un serveur de "streaming" (par exemple avec </span><a title="Stream The World" href="http://www.streamtheworld.com/en/index.php" target="_blank"><span lang="FR-CA">stream the world</span></a><span lang="FR-CA">) ce qui est en soi la meilleure option mais qui souvent implique des coûts importants. Une option intéressante pour assurer un achalandage quasi infinie pour ce genre d'application est d'utiliser un service comme le </span><a title="Amazon Simple Storage Service" href="http://aws.amazon.com/s3/" target="_blank"><span lang="FR-CA">S3 D'Amazon</span></a><span lang="FR-CA"> qui utilise la force du réseau d'Amazon (effectivement c'est bel et bien celui du magasin en ligne </span><a title="Amazon" href="http://www.amazon.com/" target="_blank"><span lang="FR-CA">Amazon</span></a><span lang="FR-CA">) et qui implique un coût ridiculement bas pour la bande passante.</span></p>
<p><span lang="FR-CA">Dans un dernier cas de figure, si on pense que notre application ou microsite sera assaillit par les utilisateurs, peu d'option s'offrent à nous. La première est de se retourné vers les services d'hébergement personnalisé où le nombre de serveurs requis sera mis en place pour affronter la charge utilisateur avec les coûts énorme que cela implique. La deuxième est d'utiliser les services d'hébergement qu'on appelle "</span><a title="Définition de Cloud Computing" href="http://en.wikipedia.org/wiki/Cloud_computing" target="_blank"><span lang="FR-CA">cloud computing</span></a><span lang="FR-CA">", la nouvelle coqueluche en fait d'hébergement de haut niveau et de flexibilité.</span></p>
<p><span lang="FR-CA">Qu'est-ce que le "cloud computing" ? Et bien c'est un type d'hébergement qui permet de configurer un type particulier de serveur qui sera automatiquement cloné en fonction de la demande utilisateur sur notre application ou microsite. Ce qui veut dire que l'application répond rapidement peu importe la demande. Et combien cela coûte-t-il ? Et bien pour la plupart des services de "cloud computing" tel que </span><a title="Mosso" href="http://www.mosso.com/index.jsp" target="_blank"><span lang="FR-CA">Mosso</span></a><span lang="FR-CA"> et </span><a title="Amazon Elastic Compute Cloud" href="http://aws.amazon.com/ec2/" target="_blank"><span lang="FR-CA">Amazon EC2</span></a><span lang="FR-CA"> les coûts sont calculé en fonction de la bande passante utilisée ainsi que les cycles de processeurs utilisés. Plus de clone nécessaire pour faire rouler votre application, plus de coûts. Les coûts au niveau de la bande passante et des cycles processeur sont extrêmement bas ce qui rend cette option encore plus intéressante.</span></p>
<p><span lang="FR-CA">Bref, il y a maintenant beaucoup de moyens de répondre à la demande des utilisateurs sans investir des sommes considérable dans des services qui sont difficile ensuite a gérer et qui demande du personnel qualifié. Seul l'avenir nous le dira mais j'ai une certaine intuition que le "cloud computing" sera le type d'hébergement le plus utilisé d'ici quelques années.</span></p>
<p class="MsoNormal"><span lang="FR-CA"> </span></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.quatrecentquatre.com/2008/12/08/comment-repondre-a-la-demande/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
