Retour

Comment est ce que Potos est construit ? Les coulisses de notre startup.

"Voici la 6ème partie des séries vidéos que je fais sur comment développer une startup en partant de rien à Paris. Ma startup s'appelle Potos, mes collègues sont Sami & Amine. Aujourd'hui je veux vous parler de la technologie qui se cache derrière Potos en vous révélant le processus de transformation d'une idée de business en code.

Chez Potos, en plus d'être le cinéaste résident, je suis le CTO. Dans une plus grande entreprise, cela voudrait dire que je sois à la tête du département tech, dans notre petite startup, cela veut simplement dire que j'écris la majeure partie du code.

Bon, écrivons un peu de code. Écrivons le code de l'application Potos. Voyons quelles sont les règles ? Eh bien, tous les mois, on débite tous les membres du groupe, puis, on sélectionne un gagnant, et, on transfère le pot au gagnant. Fini ! Nous venons de coder Potos, comme c'est génial. Non. Ce n'est pas comme ça que ça marche. Pour qu'un ordinateur puisse faire quoi que ce soit pour vous, il doit contenir aucune ambiguïté.

Quel jour dans le mois, quelle heure, quelle seconde ? Jusqu'à quand ? Pour toujours ? Quand est-ce que ça s'arrête ? Et si l'un d’eux échoue ? Combien de temps faut-il aux banques pour confirmer les transactions ? Une transaction peut-elle être confirmée initialement, puis révélée par la suite comme ayant échoué ? Qu'en est-il de la monnaie ?

Pouvez-vous sélectionner deux fois le même membre ? Non Comment pouvez-vous garantir que tout le monde gagne exactement une fois ?

Pouvons-nous transférer de l'argent directement sur une carte de crédit ? ou avons-nous besoin d'un numéro de compte et d'un code guichet ? ou peut-être d'un IBAN. En fait, qu'en est-il de toutes ces informations, qui les stocke, comment pouvons-nous les rendre sécurisées ?

Tout cela doit être fait correctement, toutes les questions doivent être posées pour que la version la plus élémentaire d'un groupe d'épargne fonctionne. Pas de folies, pas de fonctionnalités trop complexes. Ok, donc on a une version un peu plus complète d'un groupe d’épargne. Maintenant ça se complique.

Oh, l'application vient de planter c'était intentionnel pour prouver un point Cela peut arriver. En fait, ça arrive tout le temps. Il y a des milliers sinon des centaines de milliers de choses qui fonctionnent sur un serveur, qu'il s'agisse de matériel ou de logiciel. Il y a beaucoup de choses qui peuvent casser et qui venir perturber votre application.

Alors, comment faire pour contourner ce problème ? A chaque étape du processus, chaque chose importante que vous faites, doit être stockée dans une base de données. Si vous avez commencé à retirer des fonds d'un groupe de 10 personnes et que vous vous plantez après le 5ème retrait, cela devrait être dans la base de données. Si vous avez bien débité les 10 personnes et qu’avant de décider d’un gagnant, l’application casse, cela devrait être dans la base de données.

Le principe sur lequel je m'appuie lors de la conception de l'infrastructure serveur de Potos est que toute ligne de code devrait pouvoir planter, toute ligne de code devrait pouvoir faire face à une interruption à tout moment, tout devrait pouvoir casser, sans jamais que cela ne conduise à une erreur.

Pour résumer, nous avons commencé par la simple logique qui se cache derrière un groupe d'épargne, nous avons souligné les ambiguïtés qui doivent être résolus, nous y avons ajouté plus de flexibilité en ajoutant une autre variable de temps et la possibilité d'attribuer le pot à une autre personne. Puis, nous avons parlé de la résistance du système face aux crashes.

Nous n’en sommes probablement qu’à 10% de ce qui va être nécessaire pour la première version de Potos. Ce dont nous avons discuté n'est que le backend, la partie que les utilisateurs ne voient pas. Une partie frontend, une interface pour que l'utilisateur puisse voir le système est peut-être tout aussi importante. Construire un dashboard clair qui indique à l'utilisateur ce que fait exactement son groupe, quand le prochain débit sera effectué, s'il y a des problèmes. De plus, des mails devraient être envoyés pour rappeler à l'utilisateur qu'il a gagné le pot, que le gagnant lui a attribué le pot, ou qu'une personne n'a pas payé et qu'une action immédiate est requise. Peu importe la qualité du backend si les utilisateurs ne savent pas ce qu'il fait. On en reparlera peut-être une autre fois."

Restez informé de ce qui ce passe chez Potos en
vous inscrivant à notre newsletter