Um, the very definition of an administrator's role is back-end access. In any case, what you do will end up being governed by the site's permissions.
(Everything below has been edited. This shows the folly of answering from memory, as the original answer has been invalidated by changes made since the last time I'd done any extensive relying on com_contact (I basically surrendered to the spammers and took that out of almost all of my sites and drastically curtailed what it did on the rest). My apologies for misleading, and my thanks for calling me on it. while I was checking to see if permissions were still available for some groups, I should have double-checked the site output that it was still the case. It's not.)
Logged-in users should be given buttons on the front-end, but that's been removed. I understand why (it gives people not normally given access to the back end the ability to change the destination of emails sent by the system to a contact, not something that should be done as a general rule).
This means the simplest answer is adding in a different component for contact handling, one that allows for front-end editing.
If you really want to do this with com_contact, however, the way to add the button is simple, but getting more functionality out of it will require forking com_content, I'm afraid. The button code can be added in your template override by testing for permission to edit, and if it's permitted, add the button.
The fork of com_contact will need to make the model and form from the admin side usable on the site side, either directly or by copy/paste into site models, because the default "edit" form on the front-end is for sending email to the contact, not modifying the contact. You'll need to add a model analogous to the one found in 'form.php' in com_content, or simply recreate the contact form model from the admin side.
Yes, I glossed over the details for coding that, simply because covering all the details of that is a book chapter, not a StackExchange answer. It's possible to simply duplicate the admin side pieces by adding the contact admin model as use and then extending it with the PHP class, which sounds simpler but still has some bumps to smooth out.
Honestly, my best recommendations are to keep doing it via back-end or use an add-on for it; forking com_contact and all the individual maintenance that implies (especially with J!4 coming) is probably more effort than its worth.