Take Me PicTrouver, en trente secondes, quelqu’un pour te prendre en photo.
Quand un groupe veut une photo de tout le monde, quelqu’un reste toujours derrière l’appareil — et demander à un passant est lent, gênant, un peu incertain. Take Me Pic est un réseau d’entraide ancré dans un lieu et un moment : une demande diffusée aux personnes disponibles autour de soi, le premier qui accepte gagne, une conversation pour se retrouver, la photo, puis une note. Autour, un carnet de voyage communautaire et une réputation qui se gagne en aidant.
- IOS · EXPO
- SITE ET CONSOLE NEXT.JS
- SUPABASE · POSTGIS
- QUATRE LANGUES
- REVENUECAT · STRIPE
- TEMPS RÉEL
01 — Le problème
Quelqu’un reste toujours derrière l’appareil.
Un groupe veut une photo de tout le monde. Il faut soit sacrifier une personne, soit demander à un inconnu qui passe — ce qui est lent, gênant, et jamais tout à fait rassurant. Le produit part de cette scène précise plutôt que d’une catégorie d’application.
Un réseau d’entraide, pas un réseau social de plus
La formule est du client : « on y entre pour une photo, on y reste pour la communauté ». Ce qui est ancré, c’est un lieu et un moment — pas un profil qu’on entretient.
La portée a été volontairement réduite
La première phase ne traite que le cœur de l’entraide photo. Les réservations et les partenariats commerçants sont écrits, chiffrés, et repoussés jusqu’à ce que l’usage existe.
Et la pile a été choisie par ce qui existait déjà
Une réécriture en Flutter a été explicitement écartée : une maquette de vingt-sept écrans validée existait, et repartir de zéro aurait remis la vélocité réelle à zéro pour un gain de rendu marginal.
02 — La requête
Une seule requête décide si le produit fonctionne.
Tout le reste — le fil, la réputation, les conversations — dépend d’une question posée des milliers de fois : qui est disponible, tout de suite, autour de moi ? Elle est traitée comme la pièce centrale et non comme un détail d’implémentation.
PostGIS, pas une API payante
Le filtre de rayon et le tri par distance réelle passent par une extension libre de PostgreSQL, avec un index géographique dédié. Le GPS de l’appareil fournit la position ; aucun service tiers facturé n’intervient dans l’appariement.
Le premier qui accepte gagne
La demande est diffusée à toutes les personnes éligibles autour, pas adressée à une seule. L’acceptation est atomique : elle attribue l’aidant, change le statut, crée la conversation et la notification dans une seule transaction.
Une disponibilité périme
Il n’y a pas de battement de cœur, et quelqu’un qui fermait l’application restait « disponible » indéfiniment. Une fraîcheur de trente minutes a été ajoutée après le constat, et l’application relit son propre état au démarrage plutôt que de faire confiance à ce qu’elle affiche.
La confidentialité est dans la requête
La fonction d’appariement s’exécute avec des droits élevés précisément pour pouvoir lire les tables de blocage et d’exclusion, et la console d’administration ne peut jamais lire les coordonnées brutes — seule la requête d’appariement les voit.
03 — La boucle
Demander, accepter, se retrouver, noter.
C’est la promesse des trente secondes, et la seule chose qui doit être irréprochable. Chaque étape produit l’étape suivante sans que personne ait à revenir en arrière.
La position n’est partagée que pendant la séance
Hors séance active, elle ne l’est pas. C’est écrit dans la justification de permission que l’utilisateur lit avant d’accepter.
Les mesures ne portent aucune donnée
Les événements passent par un assainisseur central qui retire coordonnées, texte des messages, adresses de photos et contenu des commentaires avant l’envoi. La liste de vérification l’assert événement par événement.
Le karma récompense celui qui est noté
Et une seule des treize règles de karma prévues est réellement branchée aujourd’hui — celle des étoiles. Les douze autres sont préparées et dormantes, ce qui est écrit noir sur blanc dans l’audit plutôt que présenté comme livré.
04 — Les boutiques
Deux règles de magasin ont réécrit le produit.
Aucune des deux n’était un choix. Ce sont des contraintes externes arrivées après la conception, et la façon dont elles ont été absorbées en dit plus sur le projet que la liste des fonctionnalités.
Le rail de paiement a été coupé en deux
Le plan d’origine facturait l’abonnement par Stripe. La règle 3.1.1 d’Apple impose l’achat intégré pour tout bien numérique : l’abonnement est passé par RevenueCat et Apple, et Stripe est resté pour ce qui se passe dans le monde réel. Le modèle économique du dossier client avait été chiffré sur l’ancien rail.
Une permission a été retirée à la compilation
Les bibliothèques de choix d’image ajoutent d’office un accès large aux médias, que Google Play signale. Une extension de configuration a été écrite pour retirer ces permissions au moment de la construction — de sorte qu’aucune dépendance ne puisse les réintroduire par la porte de derrière.
Et une fonctionnalité a été retirée puis remise le même jour
Les messages vocaux exigeaient une permission de service en arrière-plan. Ils ont été supprimés le matin et rétablis dans la journée : l’arbitrage lui-même a été renversé en quelques heures. C’est ce que coûte une règle de magasin qu’on découvre après avoir livré.
- 55
- migrations de base, du premier écran au produit branché
- 43
- écrans mobiles, plus quarante-deux pages de site et soixante-cinq d’administration
- 26
- parcours de test rejoués sur l’appareil, un par tâche livrée
- 4
- langues, dont l’arabe et l’espagnol
Comptage direct des fichiers sources, dépôt DigitariaWebs/take-me-pic au commit 4ddf677 (18 août 2026) et DigitariaWebs/take-me-pic-web au commit ecff2ce. Aucune donnée d’usage n’est publiée : elle appartient au client.