Mais comment
ça marche ?

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 !

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 😎 !

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.

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 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.

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.

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 !

KERNL s'est récemment doté d'un vrai pôle design, en recrutant deux développeuses mobiles.

Nous sommes maintenant à même de réaliser des applications mobiles de bout en bout, et on ne s'est pas privé pour le faire :

On a d'ores-et-déjà pu participer à la création de l'appli Prono Racing, une ligue fantasy basée sur les vrais résultats de la Formule 1 et du Moto GP !

Et maintenant qu'on y a goûté, on en veut encore ! On a hâte de se frotter à d'autres projets mobiles. Le vôtre, peut-être ?

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.