Mais comment
ça marche ?

Nous développons pour vous, mais surtout AVEC vous. Le client est inclus dans toutes les étapes du développement : Dégrossir le projet ensemble, valider une maquette, tester l'application, nous faire des suggestions d'amélioration, intégrer vos données... On ne vous lâche pas !

Cycle de vie d’une application

Tous les développements sont uniques, mais ils passent régulièrement par les mêmes grandes phases. Si vous vous demandiez à quoi ça pouvait ressembler de collaborer avec nous, en voici un bref aperçu.

Réalisation du
cahier des charges

Dans un premier temps, on va discuter assez longuement afin de définir le besoin exact, et on établit la liste la plus exhaustive possible des fonctionnalités de l'application. Vous nous présentez votre métier, et nous on vous questionne dessus pour en obtenir une compréhension globale. Une fois qu'on a une bonne idée de ce que vous voulez, on vous propose une solution sous la forme d'un devis.

Maquette

Ensemble on va créer une maquette de l'application. Ça peut être un mockup professionnel réalisé sous Adobe XD, ou bien un dessin fait à la main sur notre tableau blanc ! Dans les faits, il nous arrive régulièrement de sauter cette étape car nos clients n'ont pas toujours une idée précise du design de leur outil. Quand c'est le cas, on démarre le développement et on vous propose des affichages qu'on pense être les plus ergonomiques pour vous, et on prend en compte vos recommandations.

Développement

On a choisi les technologies, on sait ce qu'on veut et ce dont on a besoin ? Alors on se lance ! On crée les environnements et on démarre le développement. Les démarrages sont toujours très rapides : page d'accueil, système d'authentification, base de données, ajout de données de test... On a l'habitude. Une fois qu'on est bien avancé, on vous crée un environnement de test avec tout ce qu'on a déjà pu réaliser dessus pour que vous commenciez à nous donner un premier avis.

Test

L'environnement de test est en ligne. On a mis des premières données dessus pour que ce soit concret. L'important c'est de tester les fonctionnalités qu'on a crée pour vous, et de nous faire un retour. Dans cette étape, on vous laisse généralement l'accès à notre outil de tickets. Nos développeurs interagissent directement avec vous pour mettre en place ce dont vous avez besoin, ou pour corriger les bugs que vous auriez pu rencontrer. Au besoin, on organise une réunion (présentielle, visio) pour discuter de tout ça de vive voix.

Mise en production

L'outil est prêt à être déployé. En quelques minutes on met en ligne la version 1.0 de votre site, et on y incorpore les potentielles données dont vous pourriez avoir besoin. Vous pouvez vous mettre à l'utiliser quotidiennement, mais on ne devient pas des étrangers pour autant ! Notre code est garanti pendant 3 mois après sa mise en production. Ça veut dire qu'on corrigera toujours gratuitement les bugs qu'on pourrait repérer pendant cette période.

La méthode Agile

On ne jure que par ça. Elle est largement adoptée dans le monde du développement, et repose sur deux grands principes :

Premièrement, on se fixe des objectifs courts, appelés "sprints", qu'on réalise un par un. On évite de travailler sur deux fonctionnalités en même temps, et on préférera en terminer une avant de passer à la suivante. Les différents sprints sont inscrit dans le "backlog", qui n'est rien d'autre qu'une liste de fonctionnalité à réaliser. Chez nous, ces sprints sont un ensemble de tickets Gitlab. Un ticket décrit une fonctionnalité, et peut posséder sa propre liste de tâches à cocher pour en valider le fonctionnement.

Deuxièment, la méthode Agile intègre le client dans le processus de création. Étant donné que sa satisfaction est notre priorité, on fait en sorte d'être constamment en discussion avec lui. Il valide nos développements et nous fait des remarques pour améliorer l'outil. Ainsi, on peut se permettre de lui montrer nos changements en quelques minutes, et on lui épargne des réunions à rallonge pendant lesquelles on lui présenterait une cinquantaine de fonctionnalités qu'il n'aurait pas le temps de tester.

La gestion des incidents

Le mot "bug", ou bogue en français, fait partie de notre vocabulaire journalier. Une grande partie de notre travail consiste à en corriger.

Pour traiter la découverte et la résolution des bugs plus rapidement, nous avons incorporé un outil de gestion d'incidents dans notre processus
de travail : Sentry.

Ce dernier nous permet d'être informé en temps réel de la découverte d'une erreur, au moment où l'utilisateur la rencontre. Nous pouvons alors agir de manière proactive et corriger le bug avant même que notre client nous en avertisse.

Sentry est aussi un formidable outil de débuggage. Il nous informe sur :

  • la provenance de l'incident, le fichier et la ligne de code concernés
  • l'identité de l'utilisateur qui a obtenu l'erreur
  • le type et la version du navigateur web de l'utilisateur impacté
  • la récurrence et la fréquence d'obtention de l'erreur si elle revient plusieurs fois

Grâce à cet outil, ce n'est pas rare que nous puissions constater et corriger un bug avant même que le client ne nous contacte. Ainsi on est capable de réagir en direct à ce qui se passe sur nos applications !

Questions fréquentes

On a tenté de vous présenter notre manière de travailler le plus clairement possible, mais si des questions subsistent, vous y trouverez peut-être réponse ici.

Ça dépend du temps de développement.

On est bien incapable de répondre à cette question tant qu'on ne sait pas ce qu'on doit développer. Mais on peut déjà vous dire qu'on fonctionne avec un tarif journalier, et qu'on construit notre devis dessus.

Tous les développeurs impliqués donnent leur estimation du temps que ça leur prendrait pour réaliser les fonctionnalités. On confronte nos chiffres et on en discute, pour soutenir nos points de vue.

Une fois le consensus atteint, on inscrit pour chaque fonctionnalité le nombre de jours de travail qu'on devrait lui allouer. Une rapide multiplication nous donne le prix d'une application.

On peut donc réaliser des développements très succincts, sur des outils déjà existants, qui coûtent quelques centaines d'euros. Mais il arrive aussi qu'on fasse une application énorme, sur laquelle on travaille pendant plusieurs mois, et qui coûte plusieurs dizaines de milliers d'euros.

Ca dépend de votre projet !

Tout dépend du besoin.

Encore une fois, tant qu'on ne sait pas ce qu'on doit réaliser, on ne peut pas répondre à cette question. Mais il y a d'autres paramètres qui rentrent en compte.

Est-ce qu'on démarre un projet de zéro ? Est-ce qu'on a déjà travaillé avec vous ? Est-ce qu'on connaît les technologies qu'on doit utiliser ? Est-ce qu'on recrée quelque chose à partir de rien ou est-ce qu'on réutilise du code déjà écrit ?

Il y a tout un tas de raison qui peuvent allonger ou réduire le temps de développement. Ce qu'on peut vous dire, c'est que c'est dans notre intérêt de travailler le plus efficacement possible. Un développeur, ça tente constamment d'optimiser ce qu'il fait, et ça n'aime pas réinventer la roue !

Non seulement ça, mais on a aucun intérêt à ce que nos projets traînent. Si notre client est satisfait, on peut déclarer son projet terminé, et passer à un autre. Et accessoirement le rajouter dans notre portfolio dont on est super fier 😎 !

C'est très pratique, mais pas obligatoire.

On n'attends jamais de nos clients qu'ils nous fournissent un descriptif complet des fonctionnalités attendues. Quand on l'a, on s'en sert, mais ça ne sera jamais un frein à notre collaboration.

En l'absence de cahier des charges, de documentation technique ou encore de charte graphique, on va avoir tendance à vous poser tout un tas de question dont les réponses remplacent ces documents. On a l'habitude que nos clients n'aient pas forcément une idée précise de ce qu'ils attendent.

Or, c'est notre métier de fournir des solutions numériques. Donc on sera enclin à vous faire des propositions qu'on juge ergonomiques, plus simples ou tout simplement adaptées à vos besoins.

La majorité du temps, nos collaborations commencent par des réunions où l'on discute du projet. Le client arrive avec un besoin, sans idée précise de la solution qu'il attend, et on lui propose une application qui est le point de rencontre entre nos compétences, ses moyens, et ce qu'il est techniquement possible de faire avec ces contraintes.

Non, on s'occupe de tout.

C'est déjà arrivé qu'on interagisse seulement avec le consultant technique de notre client, et ça s'est super bien passé. Mais dans la majorité des cas, nos clients interagissent directement avec nos chefs de projet, voire avec nos développeurs !

On utilise un outil de gestion de projet appelé Gitlab, qui permet la sauvegarde et le versionning de notre code, mais aussi l'édition de tickets. Si c'est nécessaire, on peut laisser l'accès à cet outil à nos clients, et ils peuvent notifier le chef de projet (ou directement le développeur concerné) pour lui poser une question, lui faire une remarque ou lui demander un changement sur l'application.

Cette façon de faire vient de la Méthode Agile, et s'incorpore à notre volonté d'intégrer le client dans le processus de développement. Ainsi on gagne beaucoup de temps en s'évitant des réunions inutiles et on humanise nos interactions. Ça nous fait du bien de vous connaître, et on pense que c'est aussi une bonne chose que vous connaissiez les humains qui se cachent derrière le code...!

Le client est propriétaire du code pour lequel il a payé.

Le code d'un développeur est considéré comme une oeuvre de l'esprit. À ce titre, il est soumis au code la propriété intellectuelle et aux droits d'auteur. En tant que prestataire, au moment de la signature d'un contrat nous décidons de céder les droits de notre code, au profit de notre client.

Dans cette optique, au moment de la livraison du projet, nous fournissons une copie complète du code, incluant toutes ses versions (grâce au soutien de Git), ainsi que la base de données.

Les outils et langage que nous utilisons sont pensés pour que les autres développeurs PHP/Laravel soient capables de reprendre notre travail et de le comprendre. Même si ça nous peine, vous pouvez confier le code à un autre prestataire, il vous appartient.

Vous pouvez confier notre travail à un autre prestataire.

On aime pas évoquer ce genre d'idées... Mais dans l'hypothèse ou notre entreprise venait à disparaître, ou que vous ne désiriez plus collaborer avec nous, vous n'êtes pas bloqué.

Étant donné que le code vous appartient, et qu'il sera compréhensible par n'importe quel autre développeur, l'application nous survivra. Vous disposez du code et de son historique complet. Chaque modification, chaque intervention d'un de nos développeurs est reportée sur le répertoire Git.

Les technologies et outils que nous utilisons sont tous open-source. Tout est fait pour que notre code soit accessible et utilisable par d'autres.

On attache d'ailleurs beaucoup d'importance à ce que notre travail soit lisible. Notre code est documenté, écrit intégralement en anglais, et suit les normes de développement de PHP, ainsi que les règles de syntaxe que nous nous sommes fixé en interne.

C'est aussi dans notre intérêt de garantir que le code peut être repris par un autre développeur, car on pourrait nous même recruter de nouveaux collaborateurs qui auront besoin de comprendre notre travail.

Vos sites et bases de données sont sauvegardées chaque jour.

Notre travail consiste justement à faire en sorte que vos services soient constamment accessibles, et que vous ne perdiez pas de données. Cela fait partie de nos considérations premières : déliverabilité, sécurité et performance.

Dans cette optique, le code est sauvegardé sur le répertoire Git, une technologie open-source très largement utilisée. Ce dernier est sur un autre serveur que votre application, et il est lui-même sauvegardé en permanence à d'autres endroits.

Quant à votre application, nous la sauvegardons chaque nuit et gardons chaque sauvegarde pendant 30 jours. Cela nous permet aussi de pouvoir revenir très facilement à une ancienne version de votre application en cas de pépin.

A titre d'exemple, lors de l'incendie d'OVH en mars 2021, 100% de nos clients impactés étaient de retour en ligne en moins de 12h, là où certains de leurs concurrents ont été hors-ligne pendant plus de deux semaines !

On peut en créer la structure applicative.

On appelle ça le "back-end", c'est le squelette et les muscles de l'application. La peau, c'est le visuel et on appelle ça le "front-end". Pour nos sites web, on réalise les deux. Mais on ne s'occupe pas du front des applis mobiles.

Le développement d'appli mobile et tablette ne fait pas partie de nos compétences, on ne réalise pas la partie visuelle. En revanche, des prestataires de notre réseau de partenaires sont tout à fait capable de se greffer sur notre back-end.

On assimilie ce fonctionnement à une API. La très grande majorité des applications de votre téléphone fonctionnent ainsi. Le front fait appel à une API pour obtenir les données, et les deux sont en quelque sorte déconnectés. Leur code n'est pas écrit au même endroit mais ils communiquent entre eux. Le front fait des appels vers une adresse internet. Notre application.

Laravel est d'ailleurs souvent utilisé pour réaliser le back-end des API. Il se prête très bien à une communication par API. On a l'habitude de développer ce genre d'outils, et ça ne nous dérange pas de ne pas réaliser le front-end.

Les deux sont possibles.

Symfony est un framework PHP développé par SensioLabs, une entreprise française, dirigée par Fabien Potencier.

Il est utilisé par près d'un quart des développeurs PHP (selon un sondage de JetBrains réalisé en 2020), et Laravel se base sur des composants de Symfony. Historiquement, il a permis des bonds en avant dans le développement web, et il reste un excellent moyen de se former à l'utilisation d'un framework.

En revanche, si nous avons choisi de privilégier Laravel, c'est pour sa clarté et sa simplicité. Un développeur Symfony qui passe sur Laravel le dira : c'est plus simple, et plus rapide pour développer.

Et au vu de la part de développeurs PHP qui utilisent désormais Laravel (la moitié !), on a misé sur le bon cheval. Parce qu'un framework très utilisé, c'est l'assurance de trouver du soutien quand on en a besoin. Il est très rare qu'on ne trouve pas de réponse sur le net quand on cherche à faire quelque chose de nouveau à partir du framework.

Pour autant, on utilise aussi Symfony. Étant donné que sa syntaxe est très proche de celle de Laravel, et qu'une grande partie de notre équipe s'est formée dessus, nous sommes tout à fait en capacité de reprendre un projet Symfony.

Les outils des artisans du web.

PHP, Laravel, Javascript, jQuery, Axios, VueJS, React, Sentry, Gitlab, Slack... On travaille avec une pluralité de technologies différentes ! C'est pas facile de s'y retrouver quand on ne vit pas dedans tous les jours. Alors on vous présente les deux plus importants, ceux dont vous entendrez forcément parler.

Attendez, PHP ?
C'est quoi ?

PHP est le langage phare du développement web : presque 80% des sites en ligne dans le monde l'utilise. Le CMS le plus connu et le plus utilisé au monde, Wordpress, est écrit en PHP.

Il a excellente réputation et est maintenu avec des mises à jours fréquentes et impactantes. Le langage fêtera bientôt ses 30 ans. 3 décennies passées à grandir, s'améliorer, se sécuriser.

D'accord, mais concrètement, c'est quoi ?

C'est un langage dit "back-end" : comprenez "interprété côté serveur". Ça veut tout simplement dire que c'est le serveur qui délivre la page web qui sera chargé d'en lire le contenu, d'appliquer la logique écrite par le développeur, et de l'envoyer dans un format lisible par votre navigateur Internet.

En clair, c'est comme une langue étrangère, qui nous permet de converser avec la machine, et de lui dire quoi faire, comment le faire. Et chez Kernl, on est plutôt du genre bilingue...! Étant tous spécialisés dans PHP, nos développeurs sont à mêmes de transformer un besoin en solution, et de le traduire en PHP pour que notre application fasse ce qu'on attend d'elle.

PHP et nous, c'est une grande histoire d'amour. Dans nos locaux, vous trouverez pas moins de 15 ans d'expérience avec ce langage. On a vu passer plusieurs mises à jour majeures, et on est toujours excité à la sortie d'une nouvelle version. Chacun d'entre nous a travaillé avec de multiples frameworks PHP, et on continue de se former chaque semaine sur les nouveautés qui en découlent.

Et l'autre là,
Laravel, kézako ?

Laravel. C'est ce qu'on appelle un Framework PHP. Imaginons que le développement web ce soit comme le bricolage. Auquel cas, Laravel c'est une boîte à outil remplie à ras-bord avec beaucoup de ce qui se fait de mieux comme matériel ! Ça nous permet de créer l'architecture de base de nos sites très vite, et d'avoir rapidement accès à des fonctionnalités de base comme l'authentification ou l'envoi d'e-mails.

Quand l’utiliser ?

Laravel est le framework PHP le plus utilisé à l’heure actuelle dans le monde (source : Sondage de 2020 réalisé par JetBrains). En France, on fait généralement la promotion de Symfony (qui est une création française !), un autre framework PHP (sur lequel Laravel s'appuie), parce que c'est un framework français. Mais nous avons choisi Laravel pour son efficacité et sa syntaxe claire ! Le framework apporte une base complète et des modules présents sur la plupart des sites web, ce qui permet de livrer et faire tester très rapidement une première version de son produit.

Parmi les autres points positifs de l'utilisation d'un framework commun, on retrouve une obligation d'écrire le code de la même façon. Chaque développeur Laravel est capable de relire le travail d'un autre, et aura tendance à utiliser la même syntaxe pour développer une fonctionnalité.

Cette boîte à outils comporte aussi des éléments de sûreté, puisque l'agence à l'origine du framework le met régulièrement à jour pour se maintenir aux standards de la sécurité informatique.

Laravel est également un bon moyen d'avoir accès à un panel d'autres modules : des petites briques applicatives qui nous permettent de rajouter des services à nos applications. Ainsi on évite de coder de zéro une fonctionnalité qu'un autre développeur a déjà réalisé, et nous propose d'utiliser. Le code de ces derniers est toujours public, et soumis au jugement des pairs. Certains d'entre nous ont même codé ou participer à la création de ces modules !

Parmi les frameworks PHP les plus connus, il y a Symfony. Il est très populaire, particulièrement en France. Une grande part des développeurs PHP sont formés dessus.

Sa place chez Kernl

Chez Kernl, on est pour ainsi dire spécialisé dans Laravel. On l'utilise tout le temps, et sa documentation technique n'a plus de secret pour nous ! En choisissant de développer sur cette même base, on se garantit une rapidité d'éxécution sans pareil.

Pour les plus expérimentés d'entre nous, ça devient très facile de venir en aide aux collègues, parce qu'on sait ce qu'on est capable de tirer du framework, et comment le faire. C'est pour toutes ces raisons qu'on propose presque systématiquement cette solution à nos clients.

Vous souhaitez en savoir plus ?

Que ce soit pour une question, une demande de devis, une remarque ou une candidature : n'hésitez pas à nous contacter via notre formulaire de contact. On se fera un plaisir de revenir vers vous pour en discuter ensemble.

   Discutons-en !