Preuves
Ce qu’on peut montrer à l’écran.
Les écrans de NakamaOS chez Nakama, les articles du blog, et le tableau « qui fait / validation » des fonctions de l’entreprise. Tout ce qu’on peut montrer à l’écran ; rien d’autre.
Ce qui se montre à l’écran
Les écrans de NakamaOS chez Nakama, reconstitués en français avec des données d’exemple. Dans le logiciel, les écrans du quotidien sont encore en anglais ; ils passent en français avant le premier client à plein tarif. Chaque scène dit ce que l’agent fait, ce que le logiciel impose, et ce qui est validé.
Ce que voit une personne qui dirige : la boîte du matin, le support, la communication, les missions de nuit, ce qui attend une décision, le produit.
-
La boîte mail a rangé les mails de la nuit : ce qui attend votre réponse, ce qui attend celle des autres, ce qui est pour information, le bruit. Elle signale les messages restés sans réponse depuis plus de cinq jours ; sur demande, elle rédige une réponse par message, dans la voix de la maison, et la relance. Validé avant envoi. NakamaOS
La boîte mail, triée chaque matin
- Ce que l’agent fait
- Le tri des messages, le signalement de ceux restés sans réponse depuis plus de cinq jours ; sur demande, une réponse rédigée par message.
- Ce que le logiciel impose
- Un brouillon est un fichier, pas un envoi : l’envoi s’arrête sur une demande de permission, « Valider » ou « Refuser ». Un message couvert par une règle de dossier confidentielle est classé par un modèle local, ou laissé de côté.
- Validé
- Chaque envoi : un devis, un contrat, une réponse à un incident.
-
Le support trie les tickets et prépare une réponse pour chacun. Avant d’écrire, il lit ce que la mémoire sait du client : anciens tickets, mails, réunions. La question qui revient devient un article d’aide. Validé avant de partir. NakamaOS
Le support, ticket par ticket
- Ce que l’agent fait
- Le tri des tickets, une réponse par ticket, l’article d’aide tiré de la question qui revient.
- Ce que le logiciel impose
- L’écran lit la file sans rien modifier. Écrire sur un ticket passe par l’outil d’action externe, qui demande la permission. La colonne « Escaladés » reprend le statut du help desk.
- Validé
- Chaque réponse ; toute escalade, toute réclamation, tout ce qui touche un contrat.
-
La communication a écrit les posts LinkedIn et X de la semaine et posé le calendrier. Un post part au clic, dans sa fenêtre de confirmation, ou à l’heure programmée. Validé avant publication. NakamaOS
Les posts de la semaine, prêts
- Ce que l’agent fait
- Les posts LinkedIn et X, le calendrier de contenu, les idées de posts.
- Ce que le logiciel impose
- Publier passe par « Valider » et sa fenêtre de confirmation, ou par une heure programmée par la personne. Un post écrit et non validé remonte dans l’écran Aujourd’hui avant son heure.
- Validé
- Chaque post, avant sa publication ou sa programmation.
-
Les missions transforment « chaque lundi, prépare les relances » en une tâche programmée qui se lance seule, à heure fixe ou sur un événement, et tient son tableau de bord dans une note. Ce qui est irréversible, envoyer ou publier, reste à valider. NakamaOS
Les missions, à heure fixe ou sur événement
- Ce que l’agent fait
- Les routines qui reviennent : un tableau de bord qui se met à jour, une liste de relances, une surveillance.
- Ce que le logiciel impose
- Une mission a un jeu d’outils réduit : elle n’écrit que dans sa zone, ne lance pas d’autre mission, n’a le navigateur que si sa note l’autorise, et s’arrête au bout de huit minutes par défaut. Elle ne peut obtenir aucune permission. Chaque passage est inscrit au journal d’activité.
- Validé
- Créer une mission, lire ce qu’elle remonte, la mettre en pause.
-
Le chef de cabinet rassemble ce qui attend une décision : les réponses préparées, les posts de la communication, les escalades du support, les missions de la nuit. NakamaOS
Ce qui attend votre décision
- Ce que l’agent fait
- La synthèse du matin, le passage de chaque demande au bon spécialiste, la mise en avant de ce qui attend une validation.
- Ce que le logiciel impose
- Chaque ligne en attente ouvre ce qu’elle désigne : le message, le brouillon, le post, la mission. Un passage de relais n’a lieu que si le classement du message est assez sûr ; sinon, la conversation reste où elle est.
- Validé
- Les décisions du matin, dans l’ordre.
-
Un tableau de bord d’exemple, tel qu’une mission peut le tenir : inscriptions, tickets, disponibilité, pull requests. Les données de cet écran sont des exemples. NakamaOS
NakamaCyber, le cas réel
- Ce que l’agent fait
- Le code, les posts « build in public », les articles du blog, le suivi des paiements Stripe, le support, les mails et les réunions.
- Ce que le logiciel impose
- Les commits écrits par un agent portent sa mention. Les permissions se donnent outil par outil et valent pour tous les agents : aucun agent n’a de droits à part.
- Validé
- Chaque réponse, chaque exercice, chaque post, avant de partir.
Les données de ces écrans sont des exemples. La disposition, elle, est celle du logiciel.
Le blog
Des guides pratiques, ce que les agents ont fait dans la semaine, nos positions.
Le blog commence avec son premier article.
Lire le blogLe tableau « qui fait / validation »
Le détail : qui fait chaque fonction chez Nakama, et sa validation. Les scénarios, eux, sont sur la page Automatisations.
- Qui fait
- la fonction, puis le prénom de l’agent ; les agents de code pour le code ; le moteur pour la sécurité des agents.
- Validé avant de partir
- ce qui envoie, publie, paie ou fusionne attend une validation.
- Le moteur
- les permissions par outil et le journal : rien à valider.
Le tableau en JSON, pour ceux qui préfèrent un script :
Télécharger le tableau (JSON) Voir toutes les automatisations Lire la journée type