Depuis que nous tenons ces chroniques, nous avons abordé un grand nombre d'aspects différents de notre vie de startupeurs (oui, startupeurs. C'est joli comme néologisme, vous ne trouvez pas ?). Mais cependant, en relisant tous les délires que nous avons pondus depuis bientôt un an, je me rend compte - à mon grand étonnement - qu'il y a un point que nous n'avons jamais évoqué... Avec quoi construit-on un système comme celui de Freedelity ? Attachons-nous donc à combler cette lacune.

Je code, donc je suis

Freedelity, c'est à la base (comme vous le savez déjà) du code. Beaucoup de code. Beaucoup beaucoup de code. A la (très grosse) louche, quelques dizaines de millions de lignes. Du Delphi quasi-exclusivement pour le moteur, un peu de PHP pour certaines classes et librairies utilisées du côté des outils d'acquisition et des applications à usage interne, pas mal de javascript pour le frontend, et une grosse pincée de Java et d'Objective-C pour les applications mobiles et industrielles.

Point de vue outil de développement pur, donc, Sébastien passe sa vie sur son IDE Delphi (qu'il pratique depuis tellement longtemps qu'il parle, pense, mange, dort et vit en Delphi). De mon côté, pas d'IDE à proprement parler ; c'est Notepad++, agrémenté d'une batterie de plugins comme Emmet, ColorPicker, NNTP ou encore TextFX, qui constitue l'essentiel de mon environnement de dev, couplé à WinSCP pour pouvoir éditer en direct sur nos serveurs (je ne suis pas fan du couple développement local/upload pour le test. Pas assez rapide).

Nécéssité oblige, nous travaillons pas mal aussi via des machines virtuelles. Le coeur de Freedelity, Kelare, tournant sous Linux, il y a donc en permanence l'une ou l'autre VM Linux ouverte sur VMWare ou Virtualbox. Ou un XP Embedded parce qu'il faut boucler une intégration sur un logiciel de caisse. Ou un environnement spécifique propre à un client particulier.

Nicolas, notre développeur industriel/mobile, jongle entre XCode pour iOS et Netbeans pour Java. Occasionnellement, il joue aussi avec des arduinos ou des rapsberry pi, manie le fer à souder et hacke des caisses enregistreuses avec un iPad et un port jack audio (c'est un ingénieur, faut l'excuser...)

Et pour nous assurer que tout cela tourne rondement, Tortoise SVN nous garantit un versioning de qualité.

Dessine-moi un mouton en CSS3, s'il te plaît...

Comme tout graphiste qui se respecte, j'ai été biberonné à Photoshop et à Illustrator. Il est donc normal que la dernière version de la Creative Suite d'Adobe occupe la majeure partie de mon SSD. Au quotidien, j'utilise assez peu de plugins - tout au plus quelques extensions comme Kuler ou BlendMeIn. J'ai ma propre bibliothèque d'actions, peaufinée et entretenue amoureusement.

Pour ce qui est du front-end de notre plateforme, il a été commencé "à la brute" (quasi en codant avec les pieds, c'est dire). Au fur et à mesure, on a évidemment réutilisé par mal d'existant, ce qui m'a amené à me constituer une petite collection de librairies et de snippets JS et CSS. Jusqu'à très récemment, je ne me basais sur aucun framework existant, ayant développé mes propres classes, mon système de grid, etc... Mais après être tombé sur un projet extrêmement novateur appellé Semantic UI, j'en suis devenu amoureux et je commence à l'intégrer de manière assez importante dans tous les nouveaux développements. A terme, il est plus que probable qu'il remplacera une bonne partie du CSS actuel.

Pour le javascript, bien entendu, c'est jQuery qui est aux commandes. La liste des plugins utilisés est aussi disparate qu'importante, ce qui nous oblige parfois à jongler avec les versions de la librairie; par exemple, notre éditeur WYSIWYG gueulera si on lui met un jQuery supérieur à la version 1.4.1, alors que la majorité des autres plugins s'appuient sur des méthodes de délégation plus évoluées que le simple .bind(), mais qui demandent une version 1.7 minimum. Cela produit parfois des résultats... intéressants. Inutile que dire qu'un gros travail d'harmonisation figure en bonne place dans notre to-do list !

Un certain temps, j'ai également pas mal utilisé des préprocesseurs CSS comme LESS ou SASS, en me constituant des petites collections de mixins. Mais avec le temps, il est apparu que la facilité de développement était pénalisée par une perte certaine des performances. J'ai donc abandonné le système pour revenir à du CSS pur, sans fioritures.

A ce propos, un petit mot : pour des raisons évidentes de facilité, nous avons décidé de ne pas supporter internet explorer versions 8 et précédentes dans les modules d'administration. Ces versions sont supportées du mieux possible dans les parties publiques du site, qui imposent une faible complexité au niveau du JS et du CSS, mais dès qu'on entre dans les fonctions avancées comme le moteur de queries, la plateforme de communication, l'éditeur HTML ou les outils analytiques, c'est IE9 minimum, Firefox ou Chrome (et encore, ce dernier est en train de devenir tellement chatouilleux et paranoïaque que j'ai de plus en plus tendance à switcher vers un navigateur Chromium-based alternatif comme Yandex).

# /usr/bin/admin

Voilà pour l'essentiel des outils sur lesquels nous passons nos journées. A côté de cela, il y a évidemment tous ceux employés par notre équipe pour leur travail quotidien : l'incontournable Office, évidemment (on a tenté le coup avec Open Office mais ce fut une catastrophe), Mozilla Thunderbird pour les mails (notre bon CEO est allergique à Outlook...), Dropbox pour le partage des fichiers avec différents niveaux d'autorisations selon les teams, Skype pour la messagerie instantanée, et Teamviewer ou LogMeIn pour la maintenance à distance.

Et puis, il y a un gros, un très gros paquet d'applications développées 100% en interne et sur mesure pour le support, l'administration, la facturation, les relances, les offres, le testing, la gestion du matériel, le suivi, etc... Je ne vais pas vous détailler tout cela, mais pour vous donner une idée de notre vision de l'efficacité, nous avons préféré consacrer trois mois à développer notre propre CRM in-house plutôt que de customiser un système existant comme Sugar CRM (que nous utilisions avant, mais qui a rapidement montré ses limites dans le cadre de nos activités).

Alors, pour conclure : à tous ceux qui n'ont pas compris un traître mot de tout ce qui précède, je présente mes excuses les plus sincères. Nous reviendrons à des considérations plus généralistes et plus existentielles dès le prochain numéro, promis juré. Et à ceux des plus barbus de nos lecteurs qui se sont exclamés "Comment ? Mais WTF, ils n'utilisent pas ... ou ... (compléter selon votre choix), quelle bande de n00bs !", je répondrai : "Les meilleurs outils ne sont-ils pas ceux qui vous garantissent une efficacité sans faille et une productivité optimale ?".

Le choix des outils que vous utiliserez est déterminant dans la manière dont vous accomplirez votre boulot. Si votre meilleur pote ne jure que par tel ou tel IDE, cela ne veut pas dire qu'il est adapté à vos besoins spécifiques. Pourquoi perdre six mois à maîtriser Photoshop si vous n'avez besoin que de convertir du JPEG en PNG ? Notre expérience nous a démontré, à de multiples reprises, qu'il est parfois plus judicieux de "perdre" quelques jours pour créer ses propres outils et être certain qu'on les maîtrisera mieux que n'importe quel autre plutôt que de s'appuyer sur des solutions toutes faites qui finiront toujours par gêner aux entournures. En plus, en agissant de la sorte, on apprend de nouvelles choses, on améliore ses capacités de créatif ou de développeur, et on peut valoriser ces nouvelles compétences dans ses divers projets. Tout bénef, win-win et tout le tralala !

Comme de coutume, je vous laisse avec un petit article relatif à la réflexion qui précède. Il illustre bien le propos que j'ai essayé de faire passer dans cette chronique, et j'ai trouvé qu'il résumait parfaitement cet état d'esprit qui devrait être propre à tout startupeur : “I build my own tools and you should too”.

Marc