Gratuit : tout MS Office et Adobe Creative Suite en quelques fiches
Fiches visio par Customguide
Le site dreamweaver gratuit vient de publier une note couvrant la sortie d’une fiche pense-bête pour la version CS3 du logiciel d’adobe. Initialement gêné par le fait que ce ne soit que pour CS3 alors que CS4 est sorti depuis quelques mois déjà, j’ai voulu creuser un peu la source citée. 2 clics plus tard, je découvre une page complète de fiches couvrant une grande majorité des outils que l’on peut utiliser aujourd’hui: la suite Office (2000 à 2007) et Adobe. Je doute qu’un pense-bête puisse faire découvrir quoique ce soit de vraiment nouveau, mais je me suis rendu compte à l’usage, que cela peut quand même vous faire gagner du temps. Ce n’est déjà pas si mal.
Cliquez-ici pour acceder à la page contenant toutes les fiches, libres de droits.
Puisqu’on aborde le sujet de la formation en ligne, je ne saurai trop vous inviter à jeter un coup d’œil sur l’excellentissime Net Tuts. Ce site, très 2.0, publie chaque jour une nouvelle formation en ligne qui peut toucher à n’importe quel logiciel, langage, technologie que vous pourriez être amener à utiliser.
Retrouvez tous les liens sur la formation en ligne en parcourant mon profil Delicious !
Comment définir les responsabilités ?
A chaque étape de la gestion de projet internet, que ce soit pour un lancement, pour une refonte ou pour des opérations de maintenance, vous aurez à définir les rôles et responsabilités des différentes parties impliquées. Par habitude, on répartira les attributions, les droits, les devoirs en fonction de l’équipe dans laquelle chacun de se trouve, chacun ayant une définition bien personnelle de ce que signifie « l’équipe opérationnelle », ou pire « l’équipe business ».
Définir les rôles dans mon projet
Comme dans beaucoup de cas, la meilleure des choses à faire est de dissiper cette brume environnante par une communication claire et surtout intelligible pour chaque membre, où qu’il se trouve. Sans chercher à réinventer la roue chaque début de trimestre, il existe une méthodologie relativement simple qui permet d’adresser ce point précis. La méthode RASIC tire son nom des rôles quelle représente :
Responsable: c’est ce que l’on appelle aussi la core-team, le nexus, le quorum… bref, l’équipe centrale qui pilote le projet et qui est associée à son succès direct.
Approbateur : il peut s’agir d’un comité de direction, d’un comité de pilotage ou d’équipes transversales étant impactées par les livrables.
Support: comme on peut s’en douter, il s’agit ici d’équipes de support dans le sens large. Au delà du classique département juridique, IT, marketing central; on veut cerner les équipes fournissant des outils, du contenu qui sera retravaillé pour le projet.
Informatif: ce groupe, souvent mal utilisé, est votre audience. Plus que des clients directs pour le projet que vous etes entrain de mener, il s’agit de votre réseau. Je ne saurai trop vous conseiller de (re)lire cet article !
Consultatif: les quelques membres qui vous aideront à accomplir les grandes étapes de votre projet sans pour autant le faire pour / avec vous. Par exemple la personne ayant modélise la première mouture d’une procédure que vous devez actualiser.
Concrètement, comment est-ce que je peux assigner une responsabilité ?
Une fois que ce modèle est clairement gravé dans notre esprit, il suffit de prendre un crayon ou sa souris et d’assigner une responsabilité par tâche. Prenons un exemple relativement commun : le couple Mme C et Mr D cherchent à vendre leur voiture, leur ami Mr A a bien vendu la sienne il y a deux mois et sa fille Mlle B l’avait aidé.
Methode RASIC : definir les roles et responsabilite
Appliqué au monde de l’entreprise, ce modèle permet non seulement de responsabiliser chacun mais aussi de clarifier les zones d’ombres. Si une action a 2 « responsables », il y a certainement de quoi creuser un petit peu, par exemple.
Dans certains cas bien précis, on pourra coupler cette matrice RASIC avec un diagramme de Gantt, notamment dans le cas de mini projet… ou de mini-équipes !
Grégory
Developper : l’url rewriting #1 – comment donner du sens à vos urls ?
Les procédures de définition d’un projet web mettent naturellement ce que l’on trouve dans le site. L’identité visuelle, l’ergonomie, les chemins que les utilisateurs devront parcourir pour atteindre leur objectifs sautent à l’esprit puisque c’est ce que l’on voit et ressent dès les premières minutes sur un site. Depuis que Google est en position de quasi-monopole dans la plupart des pays, on prend aussi en compte des mots clefs (taxonomie, règles d’édition du contenu) et d’informations moins visuelles (comme le titre des fenêtres ou les textes descriptifs des images). Ça fait déjà une longue liste de tâches à accomplir pour être au niveau par rapport à vos concurrents potentiels. La bonne nouvelle, c’est qu’il y a encore des moyens de se différencier et de marquer des points de manière efficace ou de combler votre retard actuel. Comme le nom « url rewriting » l’indique, l’idée est de reformater les urls pour leur donner plus de pertinence, de sens.
Reformater mes urls ?
En ré-écrivant des urls dynamiques, il y a de fortes chances pour que la structure qui se déploie dans la barre d’adresse de votre navigateur paraisse plus logique aux yeux de vos visiteurs. C’est déjà quelque chose que vous voyez au quotidien sans vous en rendre compte. Normal, on ne remarque que si nous parait compliqué. Ainsi, de l’exemple #1 on pourra passer à l’exemple #2 en quelques étapes.
Exemple #1:
http://www.site.com/comparaison.php?categorie=172201&c=fr&l=fr
Exemple #2:
http://voyages.site.fr/billet/avion
1er avantage: imaginons que l’on voit cette url dans les pages de résultat d’un moteur de recherche (SERP), il y a fort à parier que que les visiteurs cliquent davantage sur l’url qui comprend les mots clefs qui correspondent à leur recherche.
2ème avantage: entre deux pages comprenant un contenu globalement similaire, traitant du même sujet, sans vrai facteur différenciateur; devinez laquelle de ces pages sera indexée plus facilement que l’autre ?
Pour autant, le champ d’application de l’url-rewriting est bien plus large que ce simple exemple. En fonction des besoins de vos projets, on pourra approcher cette fonctionnalité en s’axant sur:
- la sécurité : cacher des failles potentielles liées à certains scripts,
- le SEO : améliorer le référencement naturel des pages du site et le click-through,
- le Customer Experience : les visiteurs peuvent mieux appréhender la structure du site… et on aime tous pouvoir se repérer sur un site,
- les webanalytics : imaginez un rapport de trafic / revenu (basé sur les répertoires de vos urls) qui ait du sens,
- l’opérationnel : pas besoin de changer toutes vos urls (ni de perdre le trafic ou Page Rank associé) lorsque vous lancez ou re- »brandez » un produit ou un site.
Chacun de ses points peut être une raison suffisante pour se lancer dans cet exercice.
Ok, j’en veux changer la structure de mes urls, je fais comment ?
Il existe des centaines de très bon sites qui couvrent l’implémentation technique sous les différents serveurs web qui existent aujourd’hui (enfin quand même surtout Apache et Microsoft IIS). Sans réinventer ou recopier ce qui a été fait ailleurs, voilà déjà quelques pistes qui vont vous donner de quoi commencer.
Revenons à la définition de l’url rewriting. Le principe est de de vous permettre d’écrire des règles permettant au serveur de modifier les urls des contenus recherchés par les visiteurs. On a donc bien une notion de règles (à définir) que le serveur (Apache ou IIS) devra interpréter.
Concrètement, je veux transformer quoi en quoi ?
La première étape est donc de faire un état de ce que vous avez et de voir en quoi vous voulez le transformer. Bien que cela tombe sous le sens, il est important de bien se poser la question sous différents angles. Est-ce que ce que vous pourriez imaginer sur un coin de table serait pertinent une fois que vous regarder à vos rapports de statistiques ? Est-ce votre site est la cible d’attaques incessantes contre lesquelles il faudrait penser à se protéger ?
La meilleure méthode reste de commencer à griffonner sur un bout de feuille Excel les urls type que vous avez aujourd’hui, trier celles que vous voulez reformater et imaginer comment vous pourriez les simplifier. Vous n’avez pas besoin de simplifier TOUTES les urls de votre site, une approche branche par branche peut être se révéler bien plus pertinente ou en tous cas permettre de valider les acquis et la méthode.
Comment je dis ça au serveur ?
Cette fois, cela va dépendre du langage et du type de serveur que vous utilisez pour faire tourner votre site. Il exise grosso-modo 2 types de serveurs web : Apache (qui se couple généralement avec PHP & MySQL) et Microsoft IIS (qui se couple généralement avec ASP.NET). D’après Woozweb (observatoire de sites) la part de serveurs Apache tourne autour des 80% du marché alors que IIS ne récolte que près de 20%. Apache représente a peu près 80% du marché mondial, vous trouverez par conséquent beaucoup plus de documentation à ce sujet, pour autant IIS n’est pas en reste et vous permet d’atteindre exactement les mêmes objectifs. Commençons donc avec le couple Apache & PHP.
Méthodologie sous Apache
On se bornera ici à faire quelques tests donnant des directions sur ce que vous pouvez développer de votre côté. En aucun cas il ne s’agit d’une liste exhaustive.
1. Assurez-vous que votre serveur Apache gère l’url rewriting.
Il se peut que, en fonction de votre hébergeur ou de la manière dont est configuré le serveur, les instructions ne soient pas prises en charge. Commençons par savoir si le module est actif.
Créez le fichier « info_config_apache.php » comprenant cette simple ligne de code:
<?php phpinfo(); ?>
Ouvrez votre navigateur à l’adresse en question et regardez si « mod_rewrite« fait partie des modules listés. Si ce n’est pas le cas, je vous conseille de vous reporter à la FAQ de votre hébergeur. S’il s’agit de votre propre serveur, vous trouverez toutes les démarches ici. Enfin, si vous êtes hébergés chez 1and1, l’instruction ne s’affichera pas dans la liste pas mais vous pourrez tout de même faire de l’url rewriting.
2. Essayons ensuite de passer une ou deux commandes de test pour être sur que tout fonctionne bien avant de se lancer.
En fonction de votre hébergeur (notamment en hébergement mutualisé) il se peut que vous deviez rajouter quelques lignes de code. Lancez donc votre éditeur de code, Dreamweaver ou Notepad, et créez (ou éditez) un fichier « .htaccess » à la racine de votre site. Le fichier « .htaccess » permet de faire énormément de choses très utiles dans de nombreux domaines; si vous n’en avez jamais entendu parlé, je vous conseille d’aller là et là avant de continuer. Tout le monde est revenu ? Ok, on commence donc avec ce petit bout de code:
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteRule ^perdu.html$ gagne.html [L]
Placez le à la racine de votre site, et créez au passage le fichier gagne.html. Si vous avez la flemme, téléchargez les deux fichiers en question et de-zippez les sur la racine de votre site.
Une fois les fichiers en place, il vous reste juste à tester avec votre navigateur si tout fonctionne bien. Tapez donc l’url de votre site (http://www.monsite.com/perdu.html) et vous devriez être redirigé de manière transparente vers le fichier gagner.html. Si ca marche, passez à l’étape suivante. Si ca ne marche pas (probablement « erreur 500″), essayez de retirer la première puis la troisième ligne de code du fichier .htaccess.
3. Passons maintenant à la phase finale, la mise en production de ce que vous aviez griffonné un peu plus tot.
Pour cela il existe tout un langage et une syntaxe. Je ne livrerai ici que 2 exemples typiques et des sites permettant d’approfondir.
Forcer le sous-domaine « www » ?
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^votre_site\.com$
RewriteRule ^(.*)$ http://www.votre_site.com/$1 [R=301,L]
Si vous tapez « votre_site.com », le serveur affichera et interprètera automatiquement « www.votre_site.com ». Visitez le site Apache Mod Rewrite pour creuser cet exemple.
Cacher les extensions de fichiers
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^([^\.]+)$ $1.php [NC,L]
Allez sur votre site, et vous y verrez toutes vos pages fonctionner sans le « .php », c’est à dire comme un nom de répertoire. Visitez le site Apache Mod Rexrite pour creuser cet exemple.
Dans un prochain article, nous reviendrons sur la syntaxe assez barbare utilisée ici -les expressions rationnelles- et nous verrons que cette norme est extrêmement pratique et puissante dans de nombreux domaines. D’ici là vous pouvez continuer à parcourir des exemples d’url rewriting et même d’autres possibilités offertes par la manipulation d’un fichier .htaccess.
Méthodologie sous IIS
Microsoft oblige, IIS nous offre une API pour faire ces même manipulations. On utilisera pourra utiliser l’application ISAPI (Internet Server Application Program Interface) développée par Helicon qui revient à triturer un fichier .htaccess sous Apache. On notera d’ailleurs que ISAPI 3.0 permet d’importer un fichier .htaccess, ce qui n’est pas sans intérêt. Découvrez ISAPI 3.0 et d’autres logiciels du même style .
IIS gérant nativement l’ASP.NET, vous pourrez aussi passer par une approche « code » si vous n’avez pas accès à la configuration de votre serveur. Voilà de quoi vous mettre sur la voie !
Le temps de digerez tout ca et j’aurai fini un deuxième article sur une série d’exemples prioritaires pour vos réécritures d’url sur Apache. D’ici là, commencez déjà à imaginer si certaines de vos urls devraient être réécrites et si oui, lesquelles et pour donner quel résultat ! Tout un programme.
